Re: ALTER TABLE RENAME fix

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Brent Verner <brent(at)rcfile(dot)org>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: ALTER TABLE RENAME fix
Date: 2001-11-11 00:35:02
Message-ID: 5016.1005438902@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Brent Verner <brent(at)rcfile(dot)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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Brent Verner 2001-11-11 01:26:55 Re: ALTER TABLE RENAME fix
Previous Message Brent Verner 2001-11-11 00:20:21 Re: ALTER TABLE RENAME fix