Re: Bug with plpgsql handling of NULL argument of compound type

On Fri, Jul 22, 2016 at 2:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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..

David J.