Some array semantics issues

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Some array semantics issues
Date: 2005-11-16 17:48:09
Message-ID: 9169.1132163289@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-11-16 17:59:36 Re: MERGE vs REPLACE
Previous Message Alvaro Herrera 2005-11-16 17:40:53 Re: [COMMITTERS] pgsql: make_restrictinfo() failed to attach the specified