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