Re: row() is [not] null infelicities

Greg Stark <gsstark(at)mit(dot)edu> writes:
> The SQL spec has some detailed discussion of some strange null behaviours.

BTW, Teodor Sigaev pointed out today that we are also doing array
comparisons (array_eq, array_cmp) wrong. In the recent extension
to make arrays support NULL entries, I had made these functions
treat NULL as greater than all non-nulls, per btree sort order.
But this seems wrong and also counter to spec: if an array comparison
finds a NULL before determining its result, it should return NULL,
same as a row comparison would do. The problem with this is that it
breaks btree indexing of array columns (... and I think btree indexing
of rowtypes has a problem too ...). btree wants to have a well-defined
ordering of any two non-null values. Ideas?

A nearby issue is that the spec seems to want IS [NOT] DISTINCT FROM
to drill down into array and row values, ie, comparing arrays with
these functions needs to consider null entries as comparable instead
of forcing a null result. AFAICS this will require special-casing
array and row types in IS [NOT] DISTINCT FROM ... anyone see a better
way?

regards, tom lane