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

From Stephan Szabo
Subject Re: Foreign keys for non-default datatypes, redux
Date
Msg-id 20070210110109.R30445@megazone.bigpanda.com
Whole thread Raw
In response to Re: Foreign keys for non-default datatypes, redux  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Foreign keys for non-default datatypes, redux  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, 10 Feb 2007, Tom Lane wrote:

> Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> > One side question is what should we do about the
> > places in the current system where it checks for the key sets being empty?
>
> I don't see that this affects that either way.  I can't quite imagine
> what the semantics would be, though --- there's no such thing as a
> unique constraint with no columns, so how can there be an RI constraint
> with none?

Well, the code currently has checks with comments based on SQL3
text AFAICT.       /* ----------        * SQL3 11.9 <referential constraint definition>        *      General rules 2)
a):       *              If Rf and Rt are empty (no columns to compare given)        *              constraint is true
if0 < (SELECT COUNT(*) FROM T)        *        *      Note: The special case that no columns are given cannot        *
           occur up to now in Postgres, it's just there for        *              future enhancements.        *
----------       */
 
The reason I was wondering is that it uses tgnargs == 4 as the check, and
if we change the meanings of tgnargs, we'd need to change the check.
Personally, I think we should probably just pull out the special case for
now, but thought it should be brought up.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Foreign keys for non-default datatypes, redux
Next
From: Tom Lane
Date:
Subject: Re: Foreign keys for non-default datatypes, redux