Some array semantics issues - Mailing list pgsql-hackers

From Tom Lane
Subject Some array semantics issues
Date
Msg-id 9169.1132163289@sss.pgh.pa.us
Whole thread Raw
Responses Re: Some array semantics issues  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
While hacking on the nulls-in-arrays addition, I noticed a couple of
behaviors that seem a bit bogus to me.

First, array slicing returns NULL any time the requested slice falls
completely outside the array bounds.  For instance

regression=# select ('{1,2,3}'::int[])[2:4];int4
-------{2,3}
(1 row)

regression=# select ('{1,2,3}'::int[])[3:4];int4
------{3}
(1 row)

regression=# select ('{1,2,3}'::int[])[4:4];int4
------

(1 row)

I'm inclined to think that an empty array ('{}') would be a more
sensible result.

Second, array comparison compares the contained values but pays no
attention to the array dimensions.  Thus for example

regression=# select '[0:2]={1,2,3}'::int[] = '{1,2,3}'::int[];?column?
----------t
(1 row)

regression=# select '{1,2,3,4}'::int[] = '{{1,2},{3,4}}'::int[];?column?
----------t
(1 row)

This seems pretty bogus as well.  To maintain backwards compatibility as
much as possible, I'd be inclined to sort first on the contained values
as we do now, but if they are equal sort on the array dimension data.
I'm not too concerned about exactly what the sort order is for
different-shaped arrays, I just don't think the above cases should be
considered "equal".

Comments?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: MERGE vs REPLACE
Next
From: Alvaro Herrera
Date:
Subject: Re: [COMMITTERS] pgsql: make_restrictinfo() failed to attach the specified