Gurjeet Singh writes:
> The other candidate to look for possible breakage would be pgAdmin. As Amit
> says, there might be code out in the wild that does look at this column, so
> not worth breaking them for this small gain.
Well, I already did it the other way ;-). It's probably not that big a
On Sat, Jun 16, 2012 at 5:38 PM, Tom Lane wrote:
>
> 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
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 is not specified
or if FULL is specified, ...". But I always found it rather confusing;
it sounds like we don't know what
