Re: RI triggers and schemas

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <janwieck(at)yahoo(dot)com>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: RI triggers and schemas
Date: 2002-04-01 15:39:11
Message-ID: 4199.1017675551@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck <janwieck(at)yahoo(dot)com> writes:
> Christopher Kings-Lynne wrote:
>> Why can't we just hack up the CREATE CONSTRAINT TRIGGER code to look up
>> the OIDs, etc. for the arguments and convert them internally to an ALTER
>> TABLE/ADD CONSTRAINT or whatever...

> And what language hack do you suggest to suppress the
> complete referential check of the foreign key table at ALTER
> TABLE ... time?

Actually, I was interpreting his idea to mean that we add intelligence
to CREATE TRIGGER to adjust the specified trigger arguments if it sees
the referenced trigger procedure is one of the RI triggers. It'd be
fairly self-contained, really, since the CREATE TRIGGER code could use
its "ON table" and "FROM table" arguments to derive the correct OIDs
to insert. This could be done always (whether the incoming arguments
look like OIDs or not), which'd also give us a short-term answer for
dumping/reloading 7.3-style RI triggers. I'd still like to change
pg_dump to output some kind of ALTER command in place of CREATE TRIGGER,
but we'd have some breathing room to debate about how.

I'm now inclined to leave the attribute arguments alone (stick to names
not numbers) just to avoid possible conversion problems there.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jessica Perry Hekman 2002-04-01 15:49:04 Re: timeout implementation issues
Previous Message Bradley McLean 2002-04-01 15:33:53 Proposed patch for ODBC driver w/ C-a-n-c-e-l