Thread: Array slice subscripts (was Re: [SQL] plpgsql function with more than one array argument)
Array slice subscripts (was Re: [SQL] plpgsql function with more than one array argument)
From
Tom Lane
Date:
Andre Holzner <Andre.Holzner@cern.ch> writes:
> Am I doing something wrong or is this a 'feature' ?
What's biting you is that the array slice operator uses the provided
lower bounds in the resultant array. For example:
regression=# select pcha from zdec_bhab; pcha
------------------------------------{{11,12,13},{21,22,23},{31,32,33}}
(1 row)
regression=# select array_dims(pcha) from zdec_bhab;array_dims
------------[1:3][1:3]
(1 row)
regression=# select pcha[2:2][1:3] from zdec_bhab; pcha
--------------{{21,22,23}}
(1 row)
regression=# select array_dims(pcha[2:2][1:3]) from zdec_bhab;array_dims
------------[2:2][1:3]
(1 row)
So your function receives an array with first index starting at 2,
which it's not expecting; its attempt to fetch element [1][1] is out
of bounds and produces a NULL.
Offhand this behavior seems like a misfeature: perhaps it'd be more
sensible for the extracted slice to always have index lower bounds
set to 1. But I'd like to see some discussion before changing it
(and I don't plan to touch it before 7.2 release, in any case ;-)).
Comments anyone?
regards, tom lane
Is this a TODO item?
---------------------------------------------------------------------------
Tom Lane wrote:
> Andre Holzner <Andre.Holzner@cern.ch> writes:
> > Am I doing something wrong or is this a 'feature' ?
>
> What's biting you is that the array slice operator uses the provided
> lower bounds in the resultant array. For example:
>
> regression=# select pcha from zdec_bhab;
> pcha
> ------------------------------------
> {{11,12,13},{21,22,23},{31,32,33}}
> (1 row)
>
> regression=# select array_dims(pcha) from zdec_bhab;
> array_dims
> ------------
> [1:3][1:3]
> (1 row)
>
> regression=# select pcha[2:2][1:3] from zdec_bhab;
> pcha
> --------------
> {{21,22,23}}
> (1 row)
>
> regression=# select array_dims(pcha[2:2][1:3]) from zdec_bhab;
> array_dims
> ------------
> [2:2][1:3]
> (1 row)
>
> So your function receives an array with first index starting at 2,
> which it's not expecting; its attempt to fetch element [1][1] is out
> of bounds and produces a NULL.
>
> Offhand this behavior seems like a misfeature: perhaps it'd be more
> sensible for the extracted slice to always have index lower bounds
> set to 1. But I'd like to see some discussion before changing it
> (and I don't plan to touch it before 7.2 release, in any case ;-)).
>
> Comments anyone?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Re: Array slice subscripts (was Re: [SQL] plpgsql function with more than one array argument)
From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Is this a TODO item?
I guess so, since no one seems to have objected to the proposed change.
It's a pretty trivial change; I'll take care of it.
regards, tom lane
> Tom Lane wrote:
>> Andre Holzner <Andre.Holzner@cern.ch> writes:
> Am I doing something wrong or is this a 'feature' ?
>>
>> What's biting you is that the array slice operator uses the provided
>> lower bounds in the resultant array. For example:
>>
>> regression=# select pcha from zdec_bhab;
>> pcha
>> ------------------------------------
>> {{11,12,13},{21,22,23},{31,32,33}}
>> (1 row)
>>
>> regression=# select array_dims(pcha) from zdec_bhab;
>> array_dims
>> ------------
>> [1:3][1:3]
>> (1 row)
>>
>> regression=# select pcha[2:2][1:3] from zdec_bhab;
>> pcha
>> --------------
>> {{21,22,23}}
>> (1 row)
>>
>> regression=# select array_dims(pcha[2:2][1:3]) from zdec_bhab;
>> array_dims
>> ------------
>> [2:2][1:3]
>> (1 row)
>>
>> So your function receives an array with first index starting at 2,
>> which it's not expecting; its attempt to fetch element [1][1] is out
>> of bounds and produces a NULL.
>>
>> Offhand this behavior seems like a misfeature: perhaps it'd be more
>> sensible for the extracted slice to always have index lower bounds
>> set to 1. But I'd like to see some discussion before changing it
>> (and I don't plan to touch it before 7.2 release, in any case ;-)).
>>
>> Comments anyone?
>>
>> regards, tom lane
Hello developpers,
Tom Lane wrote:
>
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Is this a TODO item?
>
> I guess so, since no one seems to have objected to the proposed change.
> It's a pretty trivial change; I'll take care of it.
>
> regards, tom lane
I learned to live without it, but I wont be the last one
who tries to use such queries.
best regards & thanks a lot for your efforts,
André
>
> > Tom Lane wrote:
> >> Andre Holzner <Andre.Holzner@cern.ch> writes:
> > Am I doing something wrong or is this a 'feature' ?
> >>
> >> What's biting you is that the array slice operator uses the provided
> >> lower bounds in the resultant array. For example:
> >>
> >> regression=# select pcha from zdec_bhab;
> >> pcha
> >> ------------------------------------
> >> {{11,12,13},{21,22,23},{31,32,33}}
> >> (1 row)
> >>
> >> regression=# select array_dims(pcha) from zdec_bhab;
> >> array_dims
> >> ------------
> >> [1:3][1:3]
> >> (1 row)
> >>
> >> regression=# select pcha[2:2][1:3] from zdec_bhab;
> >> pcha
> >> --------------
> >> {{21,22,23}}
> >> (1 row)
> >>
> >> regression=# select array_dims(pcha[2:2][1:3]) from zdec_bhab;
> >> array_dims
> >> ------------
> >> [2:2][1:3]
> >> (1 row)
> >>
> >> So your function receives an array with first index starting at 2,
> >> which it's not expecting; its attempt to fetch element [1][1] is out
> >> of bounds and produces a NULL.
> >>
> >> Offhand this behavior seems like a misfeature: perhaps it'd be more
> >> sensible for the extracted slice to always have index lower bounds
> >> set to 1. But I'd like to see some discussion before changing it
> >> (and I don't plan to touch it before 7.2 release, in any case ;-)).
> >>
> >> Comments anyone?
> >>
> >> regards, tom lane
--
------------------+----------------------------------
Andre Holzner | +41 22 76 76750
Bureau 32 2-C13 | Building 32
CERN | Office 2-C13
CH-1211 Geneve 23 | http://wwweth.cern.ch/~holzner/