Re: ALTER TABLE RENAME fix - Mailing list pgsql-patches

From Tom Lane
Subject Re: ALTER TABLE RENAME fix
Date
Msg-id 5016.1005438902@sss.pgh.pa.us
Whole thread Raw
In response to Re: ALTER TABLE RENAME fix  (Brent Verner <brent@rcfile.org>)
Responses Re: ALTER TABLE RENAME fix  (Brent Verner <brent@rcfile.org>)
List pgsql-patches
Brent Verner <brent@rcfile.org> writes:
> Yes, but I'm doing two separate scans for relname's OID; tgrelid and
> tgconstrrelid.

Oh!  Duh ... I managed to miss that completely.  You're right, the
scan for tgconstrrelid should catch the "other half" triggers that
I was worried you'd miss.  The code is kinda misleadingly structured,
since it looks at both RI_FK_RELNAME_ARGNO and RI_PK_RELNAME_ARGNO in
each loop, which is really wrong: ISTM you should be examining only one
of those, depending on whether you found the trigger by tgrelid or
tgconstrrelid, and it shouldn't be necessary to look at the stored
relname at all should it?

> The second scan returns tuples where tgrelid is the
> OID of the other relname in the constraint.  Is there a way to do
> this in one scan?

I don't think so, but it seems like you could avoid the duplicated code
by having a subroutine that's invoked twice with two different parameter
sets.

Each of the scans could be indexscans (but using two different indexes,
viz pg_trigger_tgconstrrelid_index and pg_trigger_tgrelid_index), so
it should still be plenty fast enough.

            regards, tom lane

pgsql-patches by date:

Previous
From: Brent Verner
Date:
Subject: Re: ALTER TABLE RENAME fix
Next
From: Brent Verner
Date:
Subject: Re: ALTER TABLE RENAME fix