Alvaro Herrera <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to