From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RI triggers and schemas |
Date: | 2002-04-01 06:00:48 |
Message-ID: | 20020331215537.U11990-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 31 Mar 2002, Tom Lane wrote:
> Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
> > 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...
>
> Hmm ... seems pretty ugly, but then again the alternatives are pretty
> durn ugly themselves. This ugliness would at least be localized.
> Might be a plan.
Yeah, although it'd still be a good idea probably to convert the dump form
to ALTER TABLE in any case. The one downside that was brought up in the
past was the time involved in checking dumped (presumably correct) data
when the constraint is added to very large tables. I can probably make
that faster since right now it's just running the check on each row,
but it'll still be slow on big tables possibly. Another option would
be to have an argument that would disable the check on an add constraint,
except that wouldn't work for unique/primary key.
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2002-04-01 07:08:30 | Re: RI triggers and schemas |
Previous Message | Christopher Kings-Lynne | 2002-04-01 06:00:30 | Re: RI triggers and schemas |