Thread: ALTER TABLE .. OWNER TO and sequences

Patchers,

Here is a patch regarding ALTER TABLE ... OWNER and the sequences that
were created by a SERIAL column.

It uses pg_depend to find SERIAL sequences, and recurses the ChangeOwner
to them.  Additionally, it forbids directly changing the owner of a
SERIAL sequence (the error message of this last action needs to be
perfected).

I also added some regression tests for ALTER TABLE ... OWNER, because
previously there wasn't any.

According to my testing, this fixes the issue with pg_dump not restoring
the ownership of SERIAL sequences and the annoyance of having to alter
the sequence manually (the principle of least surprise indicates that
the sequence should be altered automatically).

Please review.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Now I have my system running, not a byte was off the shelf;
It rarely breaks and when it does I fix the code myself.
It's stable, clean and elegant, and lightning fast as well,
And it doesn't cost a nickel, so Bill Gates can go to hell."

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> Here is a patch regarding ALTER TABLE ... OWNER and the sequences that
> were created by a SERIAL column.

Applied with some changes.  I tightened up the checks on the pg_depend
entries, just for paranoia's sake.  (At the moment I don't think there
could be any entries that would wrongly get by the tests you had, but
I'd rather verify that it's an INTERNAL dependency, for instance.)

> Additionally, it forbids directly changing the owner of a
> SERIAL sequence

I did not apply this part because it's inconsistent with the behavior
for indexes.  If you want to argue that we should disallow changing
index ownership separately as well, we can talk about that ...

> I also added some regression tests for ALTER TABLE ... OWNER, because
> previously there wasn't any.

I didn't apply these either, because I thought them more likely to cause
bogus regression failures than detect any real problems in the field.
Two reasons they could do so are (1) running the regress tests as a
superuser other than ID 1; (2) running the tests in an installation that
already has a userid 42.  We could avoid (2) by reporting user names
instead of sysids, but that doesn't fix the superuser problem.

            regards, tom lane