Christopher Kings-Lynne wrote:
> > I've just realized that if we change the RI trigger arguments this way,
> > we will have a really serious problem with accepting pg_dump scripts
> > from prior versions. The scripts' representation of foreign key
> > constraints will contain commands like
> >
> > CREATE CONSTRAINT TRIGGER "<unnamed>" AFTER UPDATE ON "bar" FROM "baz" NOT DEFERRABLE INITIALLY IMMEDIATE FOR EACH
ROWEXECUTE PROCEDURE "RI_FKey_noaction_upd" ('<unnamed>', 'baz', 'bar', 'UNSPECIFIED', 'f1', 'f1');
> >
> > which will absolutely not work at all if the 7.3 triggers are expecting
> > to find OIDs in those arguments.
>
> 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? Currently, it does a sequential scan of the entire table to check every single
row. So adding 3 constraints to a 10M row table might take some time.
Note, that that language hack will again make the dump non- ANSI complient and thus, I don't consider the
entire change to ALTER TABLE an improvement at all.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
