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:

Previous
From: Tom Lane
Date:
Subject: Re: ALTER TABLE RENAME fix
Next
From: Tom Lane
Date:
Subject: Re: ALTER TABLE RENAME fix