Re: BUG #6701: IS NOT NULL doesn't work on complex composites

Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@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