From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Markus Bertheau ☭ <twanger(at)bluetwanger(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: [SQL] ARRAY() returning NULL instead of ARRAY[] resp. |
Date: | 2005-06-07 01:24:52 |
Message-ID: | 42A4F764.9010705@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches pgsql-sql |
Markus Bertheau ☭ wrote:
> Hmm, this gets really complicated and inconsistent. Complicated means
> unusable. What about modifying the dimension syntax such that the second
> number means number of elements instead of upper bound? That particular
> problem would go away then, and array_upper('[0:0]={}'::int[]) can
> return the correct 0 then.
>
> What I'm actually worrying about is that array_upper(array(select 1
> where false)) returns 0.
>
> An option would be to drop the possibility to let the array start at
> another index than 0. I don't know why it was decided to do that in the
> first place. It seems a rather odd feature to me.
>
Actually I like both of these ideas, and have advocated the second one
myself before. But it isn't backward compatible -- anyone else have an
opinion? SQL2003 actually specifies that an array *should* start at 1:
4.10.2 Arrays
An array is a collection A in which each element is associated with
exactly one ordinal position in A. If n is the cardinality of A, then
the ordinal position p of an element is an integer in the range 1 (one)
≤ p ≤ n.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Tillotson | 2005-06-07 01:26:21 | Re: [COMMITTERS] pgsql: Fix NUMERIC modulus to properly |
Previous Message | Bruce Momjian | 2005-06-07 01:23:21 | Re: libpq API incompatibility between 7.4 and 8.0 |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2005-06-07 02:02:55 | Re: using strxfrm for having multi locale/please vote for adding this function in contribution |
Previous Message | Bruce Momjian | 2005-06-07 01:23:21 | Re: libpq API incompatibility between 7.4 and 8.0 |
From | Date | Subject | |
---|---|---|---|
Next Message | Kenneth Gonsalves | 2005-06-07 05:29:17 | preventing deletion of a row |
Previous Message | Markus Bertheau | 2005-06-06 23:16:52 | Re: SQL equivalent to nested loop |