From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | s/UNSPECIFIED/SIMPLE/ in foreign key code? |
Date: | 2012-06-16 21:38:18 |
Message-ID: | 11331.1339882698@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Our foreign-key-related code uses MATCH_UNSPECIFIED to denote the
default foreign key match behavior. This corresponds to the wording
used in the SQL92 spec, for instance "If <match type> is not specified
or if FULL is specified, ...". But I always found it rather confusing;
it sounds like we don't know what match behavior we're supposed to
implement.
I notice that in SQL99 and later, the SQL committee introduced "MATCH
SIMPLE" as a way to name the behavior that formerly had no name.
So now they can write things like "If M specifies SIMPLE or FULL, ..."
which seems much nicer to me.
I think it would be a useful advance in readability if we replaced
UNSPECIFIED by SIMPLE throughout the FK code, and barring objections
I will go do that.
A small flaw in this plan is that in pg_constraint.confmatchtype,
MATCH_UNSPECIFIED is stored as 'u'. In a green field I'd just rename
that to 's' for SIMPLE, but it seems possible that this would confuse
client-side code such as pg_dump or psql. A quick look shows that
neither of those programs actually look directly at
pg_constraint.confmatchtype, instead relying on backend functions when
they want to deconstruct a foreign key constraint. But there could well
be other client code that would notice the change. So I'm a bit torn
as to whether to change it and create a release-note-worthy
compatibility issue, or to leave it as-is (with documentation notes that
"u" for MATCH_SIMPLE is a historical accident).
Thoughts?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2012-06-16 21:50:27 | Re: sortsupport for text |
Previous Message | Dean Rasheed | 2012-06-16 20:28:45 | Re: SQL standard changed behavior of ON UPDATE SET NULL/SET DEFAULT? |