Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)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