On Mon, Sep 14, 2009 at 10:22 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
