Re: REVIEW: Optimize referential integrity checks (todo item) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: REVIEW: Optimize referential integrity checks (todo item)
Date
Msg-id 7343.1340022646@sss.pgh.pa.us
Whole thread Raw
In response to Re: REVIEW: Optimize referential integrity checks (todo item)  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> I think that the patch already covers the most common use case (in my
> experience) but we may as well get as much out of it as we can while
> we're here.

Yeah.  The cases involving nulls are probably really rather unlikely
altogether, but it seems a tad silly to fix only some of them when
we can fix all of them for marginally more effort.

> Are you planning to tackle this, or should I move the patch back to
> "waiting on author" to give Vik Reykja a chance to update it?

It doesn't look like much else is "ready for committer" yet, so I think
I'll keep hacking on this one.  The whole of ri_triggers is looking a
bit old and creaky to me; for instance the SET DEFAULT triggers believe
that they can't cache plans involving DEFAULT, which was fixed years
ago (I'm pretty sure that the plancache level should take care of that
automatically, since an ALTER TABLE ... DEFAULT command would force a
relcache flush).
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: s/UNSPECIFIED/SIMPLE/ in foreign key code?
Next
From: Andres Freund
Date:
Subject: Re: [PATCH 06/16] Add support for a generic wal reading facility dubbed XLogReader