Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >> So currently a NOT NULL constraint on a column with a composite >> type is equivalent to: >> CHECK (NOT c IS NULL) > > I don't believe this statement is accurate. What's really > happening is that a column-not-null constraint is a > datatype-independent check for whether the datum per se is null or > not. I stand corrected. > Somebody who really cares about having the SQL-spec definition can > write a CHECK constraint as suggested above, and then he'll get > the composite-type-aware behavior, so it's not like there's no way > to get that. > > BTW, the same inconsistency exists for function-argument > strictness checks: those will consider a heaptuple-of-all-nulls to > be something you can call a strict function with. I think > changing this would be a pretty bad idea, not only on modularity > and performance grounds but because it'd likely break existing > applications that expect the current behavior. Maybe a comment or two in the docs covers it? > regression=# select null::int8_tbl is distinct from > row(null,null)::int8_tbl; > ?column? > ---------- > t > (1 row) > > It's not clear to me whether the SQL standard rules on what should > happen in this case, or whether we should listen to it if it does > say that these values are not distinct. They certainly *look* > distinct. I do sympathize with the point of view that a row value about which absolutely no applicable facts are known is a lot like not knowing what row you have, but they do seem distinct when you look at the output. > (Oh, and dare I mention arrays of nulls?) Hey, look! An elephant! -Kevin
-- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
