Re: BUG #5053: domain constraints still leak

On Mon, Sep 14, 2009 at 10:22 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> It seems like regardless of this discussion you oughtn't to be able to
>> store a NULL into that table column.  But maybe I'm just confused.
>
> The system is relying on the not-unreasonable assumption that if it
> extracts a column of type X from someplace, what it has is a valid value
> of type X.  Depending on what we decide about the whole composite-null
> mess, maybe we will be forced to abandon that assumption ... but I'm
> sure not going to do so until my back is to the wall.

I haven't read the code in this area, but for what it's worth, I guess
I lean toward the view that treating a row of NULLs as being the same
thing as an undecorated NULL does not make very much sense. If I have
a table row which contains (1, NULL, NULL) and I update the first
column to be NULL, I feel like I now have (NULL, NULL, NULL), not just
NULL. Every other programming language I'm aware of makes this
distinction - for good reasons - and I don't really see any reason why
SQL should do anything different.

Under that view, null::test is not itself a test, but denotes the
absence of one. Trying to store this value in a table can either fail
outright (on the theory that you can't store the absence of something
in a table), or else we can - as a special case - treat assignment
from null to an actual object as a request to assign null to each
column (which will fail if there exists a column into which a NULL of
the associated column type can't be stored).

...Robert