Define pg sequence owned by

[albertlast]

two possible issues get fixed,
first that default script can't find the sequence found by @sbulen see #6319 (comment)
second issue is, that a sequence survive a table drop.
When now a table get dropped the sequence get deleted too.

in short sequence beahvior more like a ai field -> good for smf.

[jdarwood007]

Don't know much about postgres as I should, but since your querying global tables and modifying stuff, is there a chance this could fail in typical standard shared hosting conditions where an account may have limited access to certain data?

[albertlast]

Couldn't image since are basic tabell otherwise the client is not able to work,
also i only select tables which start with the smf prefix.

had in mind, that smf 2.1 is not enabled for running in other schemas than public -> ther can not be other smf setups in the same db.

[albertlast]

i limited to the public schema is this in your favor?

[sbulen]

I really don't think this should be done by navigating the catalog...

Why didnt you just add ALTER SEQUENCE OWNED BY ... statements?

[jdarwood007]

@albertlast I'm more concerned how this would function in shared hosting where information like this may be limited or restricted. I don't have a postgres instance in a shared hosting space to even know. If your saying this will always produce results even in shared hosting, then thats awesome.

[albertlast]

I really don't think this should be done by navigating the catalog...

Why didnt you just add ALTER SEQUENCE OWNED BY ... statements?

a source of error,
for get it on one of the 42 sequence and you will never notice to the point where it to late.
better way would be to use serial and use catalog to find the sequence when we need to access them directly.

[sbulen]

Yes - The SMF database has 42 sequences. This is known & finite. Each is tied to a table & column. The names have not changed over time.

The install_2-1_postgresql & upgrade_2-1_postgresql files each simply need those 42 DDL clauses added.

If we had to support a dynamic DB structure for some reason, it would make sense to query the catalog. But we don't...

This is a 'keep it simple' moment. Adding the clauses is sufficient.

[albertlast]

nope 146 lines are needed for the 42 seq to be the same,
in your pourpose.
it's high source of issues.

[sbulen]

And the database runs just fine without them... No reason to do this dynamicaly mid-operation.

The ONLY impacts are when you drop tables. And even then... Worst-case scenario... You can delete the sequences if needed. It's actually OK to leave them as-is.

[sbulen]

What issues? There is NO bug reported here...

[albertlast]

i mention both above,
should i open this?

[Sesquipedalian]

Note: This PR targets release-2.1, but it has been assigned to the milestones for SMF 3.0. The PR will need to be updated and resubmitted to target release-3.0. I am leaving it open for now so that it doesn't get forgotten.