Re: ALTER TABLE RENAME fix

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ALTER TABLE RENAME fix
Дата
Msg-id 5016.1005438902@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ALTER TABLE RENAME fix  (Brent Verner <brent@rcfile.org>)
Ответы Re: ALTER TABLE RENAME fix  (Brent Verner <brent@rcfile.org>)
Список 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 по дате отправления:

Предыдущее
От: Brent Verner
Дата:
Сообщение: Re: ALTER TABLE RENAME fix
Следующее
От: Brent Verner
Дата:
Сообщение: Re: ALTER TABLE RENAME fix