Re: row() is [not] null infelicities - Mailing list pgsql-hackers

From Tom Lane
Subject Re: row() is [not] null infelicities
Date
Msg-id 11828.1152505027@sss.pgh.pa.us
Whole thread Raw
In response to row() is [not] null infelicities  (Greg Stark <gsstark@mit.edu>)
Responses Re: row() is [not] null infelicities  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
Greg Stark <gsstark@mit.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


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: pgsql-patches considered harmful
Next
From: Tom Lane
Date:
Subject: Re: pgsql-patches considered harmful