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

On 10 Nov 2001 at 21:41 (-0500), Tom Lane wrote:
| Brent Verner <brent@rcfile.org> writes:
| > | But we do, because we know whether we're scanning by tgrelid or
| > | tgconstrrelid.
|
| > My brain is not stretching far enough to see this.  Yes, we know
| > what we are scanning on, but that stilll doesn't tell us which
| > side of the FK/PK relation this relname is on.
|
| Doesn't it?  Maybe I'm the one who's confused.  The RI trigger functions
| certainly know which field is which without any searching.
 [snip]
| Hmm, so the same tgargs vector is passed to all the triggers regardless
| of which side of the relationship they're on, and it's up to the trigger
| itself to know which relname/attname applies to its own table.

exactly. which is why we've gotta inspecy the relname to determine
which of the attnames to modify.

| I think what this means is that a boolean "is_ri_trigger" classification
| isn't good enough.  You need to make the knowledge function have a
| three-way return: not an RI trigger, RI trigger for PK relation, or
| RI trigger for FK relation.  Then the scan subroutine has to take two
| item-number parameters, one telling it which tgarg item to look at for a
| PK relation and a different one to look at for an FK relation.

I'm not sure why this is necessary.

  A scan on tgrelid==relname.oid returns an RI trigger.
  A scan on tgconstrrelid==relname.oid returns an RI trigger.

We must update these tuples.  We can't know if the relname being
modified is the PK or FK, and it really doesn't matter, because
its name or attname must be updated to refer to the new name.  This
is why I'm checking relname in either the PK or FK position for
each tuple.  Is there a case where updating these tuples tgargs
to contain the new relname|attname would break things?  If not, I
believe my 'update all references to the oldname' behavior is
acceptable, and even correct :)

| Or maybe some slightly different structure would be cleaner.  But the
| point is that you have to be able to decide which item to look at
| by some means that doesn't involve checking the relname item.  Else it
| doesn't work for self-referential RI constraints (same relname on
| both sides).

do you have a bit of sql in mind so that I might test this
self-referential RI constraint?

| > AFAICS, given a relname, the only way we can know if it is the PK or
| > FK is the number of tuples a known scan returns.
|
| The number of tuples is an implementation artifact and might change;
| I don't think we should trust that.  (For example, RI_FKey_noaction_del
| and RI_FKey_cascade_upd could theoretically be merged into a single
| trigger that pays attention to the event it was called for.)

right.  I was not proposing that as any bit of info to use, just an
example that there is no useful way (in a pg_trigger scan) to know
if the relname is a PK or FK rel.

cheers.
  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