Re: Foreign keys for non-default datatypes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Foreign keys for non-default datatypes
Date: 2006-03-04 00:22:22
Message-ID: 9408.1141431742@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephan Szabo 2006-03-04 00:37:25 Re: Foreign keys for non-default datatypes
Previous Message Tom Lane 2006-03-03 23:36:23 Re: Problemas with gram.y