Re: newbie: renaming sequences task

craigp <craigp98072(at)yahoo(dot)com> writes:
> I was perusing the todo list to see some easy items that I might help out on (and get up to speed on postgres hacking)... one of them (with %) seems to lead to another:
> ...
> But I'm left a bit confused on what, if anything, can or should be done. Maybe this isn't the best item to start with? If I had some more direction, it might be straightforward enough.

No, the reason those are still on the TODO list is that it's not
straightforward.

The first one is really not related to the others --- it just proposes
that when renaming a table or individual column, we should look for
sequences "owned by" that column or columns, and rename them so that
they still look like "table_column_seq". This is about 50%
straightforward searching of pg_depend, and about 50% dealing with
collisions --- if there's already something of that name, you'd need
to go through the same type of fallback name selection that's already
done when a serial column is first made.

(Thinking about it, I kinda wonder whether we even *want* such behavior
anymore. In the presence of ALTER SEQUENCE ... OWNED BY, it's entirely
possible that an owned sequence has a name that's got nothing to do with
table_column_seq, and which the user wouldn't really want us to forcibly
rename. Maybe this TODO has been overtaken by events?)

The second one is not about that, but about wishing that the sequence
name that (for purely historical reasons) is stored in the sequence's
data row would track ALTER SEQUENCE RENAME. The problem here is that
ordinary sequence operations like nextval() are nontransactional, and
it's hard to mix transactional and nontransactional updates of the same
row. There's been talk of rearranging the representation of sequences
to fix this, but nothing concrete. The only concrete solution offered
has been to remove that copy of the name, which would be simple but not
backwards compatible.

The third one is a semi-independent feature wish, namely for a single
system table or view in which all sequences' parameters could be seen.
(An example of the usefulness of that is that it's currently extremely
hard to get psql's \dS to show sequence parameters, because we can't
join dynamically to individual sequences.)

The tie between #2 and #3 is mostly just not wanting to repeatedly
whack around the representation or user-visible properties of sequences.
If we're going to do both things they should happen in the same update.

I'm not sure that #2 or #3 is a suitable first hacking project. The
real task underlying both of them is "redesign the representation of
sequences in a way that has the right combination of transactional and
nontransactional behaviors, and try to make sure that it'll scale to
lots and lots of sequences".

regards, tom lane