On Fri, Jul 22, 2016 at 2:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
There is a rather squishy question as to whether NULL::composite_type should be semantically equivalent to ROW(NULL,NULL,...)::composite_type. If it is, then the SELECT should have failed before even getting into the plpgsql function, because ROW(NULL,NULL) is surely not a valid value of type c. The SQL standard seems to believe that these things *are* equivalent (at least, that was how we read the spec for IS [NOT] NULL).
I dislike that they are considered equal in various circumstances but if that's we are guided toward c'est la vie.
FWIW, there is a very good argument that any not-null restriction on a datatype (as opposed to a stored column) is broken by design. How do you expect a LEFT JOIN to a table with such a column to work?
As described - except "NULL::composite_type" isn't atomic.
I/we would like: If you have a non-null value of this composite type then the first field of the composite must itself be non-null.
We certainly are not going to enforce the not-nullness in that context, and that leads to the thought that maybe we should just deny the validity of such restrictions across the board.
Soft or hard we should do this. Being allowed to set NOT NULL on a domain with these traps built into the architecture is just asking for angry users when their data model fails to be usable throughout their application. The only thing we can offer is that we will respect NOT NULL during the persisting a record to storage..
