Re: Foreign keys for non-default datatypes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Foreign keys for non-default datatypes
Date
Msg-id 9408.1141431742@sss.pgh.pa.us
Whole thread Raw
In response to Re: Foreign keys for non-default datatypes  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Responses Re: Foreign keys for non-default datatypes  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Re: Foreign keys for non-default datatypes  (Michael Glaesemann <grzm@myrealbox.com>)
List pgsql-hackers
BTW, I had another thought about this: if we go this way, then the plans
associated with RI check queries would essentially always be trivial
index lookups (for everything except RI_Initial_Check).  It'd be within
the realm of feasibility to throw away the current cached-plan RI
infrastructure and simply do direct indexscans, in the style that we
currently use for most system-catalog accesses.  I have never done any
performance testing or profiling of routine foreign-key check operations
but I should think that this would be really significantly faster ---
and it'd let us get rid of some ugly warts that we've had to plaster
onto SPI and the executor to support RI semantics, such as the
"crosscheck snapshot" cruft.

If we did this then RI checks would no longer be subvertible by rules or
user triggers.  Although I've been heard to argue that that's a feature,
I think the majority of people feel it's a bug, and wouldn't be sorry to
see it go.

Comments?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Problemas with gram.y
Next
From: Stephan Szabo
Date:
Subject: Re: Foreign keys for non-default datatypes