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 ROW EXECUTE 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. #
#================================================== [EMAIL PROTECTED] #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
