Re: ALTER TABLE RENAME fix - Mailing list pgsql-patches
From | Brent Verner |
---|---|
Subject | Re: ALTER TABLE RENAME fix |
Date | |
Msg-id | 20011110202655.A98369@rcfile.org Whole thread Raw |
In response to | Re: ALTER TABLE RENAME fix (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: ALTER TABLE RENAME fix
Re: ALTER TABLE RENAME fix |
List | pgsql-patches |
On 10 Nov 2001 at 19:35 (-0500), Tom Lane wrote: | 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? <light bulb over head> no doubt, very badly/misleadingly written. There is no reason for me to reconstruct the new tgargs for each tuple at all. I just need to do the check against PK_RELNAME and FK_RELNAME for the first tuple that needs updating, since the tgargs is the /same/ for all calls to this trigger... but we have to check both PK_RELNAME and FK_RELNAME, since we don't know which side of the constraint this relname is on. The following pseudo-code describes all I need to do. newtgargs = NULL; while(tuple = scan(tgrelid==relname.oid)){ if( is_ri_trigger(tuple) ){ if( newtgargs == NULL ){ get_newtgargs(tuple,newtgargs); } update_tgargs(tuple,newtgargs); } } while(tuple = scan(tgconstrrelid==relname.oid)){ if( is_ri_trigger(tuple) ){ update_tgargs(tuple,newtgargs); } } | > 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. Yeah, I started to do this anyway, since making the same change in two places was just painful ;-) | 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. I'll make it so. Thanks, Brent -- "Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing." -- Duane Allman
pgsql-patches by date: