Skip site navigation (1) Skip section navigation (2)

Re: Support for negative index values in array fetching

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, "Valtonen, Hannu" <hannu(dot)valtonen(at)hut(dot)fi>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Support for negative index values in array fetching
Date: 2011-01-05 12:08:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2011/1/5 Florian Pflug <fgp(at)phlo(dot)org>:
> On Jan5, 2011, at 10:25 , Peter Eisentraut wrote:
>> On sön, 2011-01-02 at 12:47 +0100, Florian Pflug wrote:
>>> The only way around that would be to introduce magic constants "lower", "upper" that
>>> can be used within index expressions and evaluate to the indexed dimension's lower
>>> and upper bound. You'd then use
>>>  my_array[upper], my_array[upper-1], ...
>>> to refer to the last, second-to-last, ... element in the array. Actually doing this
>>> could get pretty messy, though - not sure if it's really worth the effort...
>> How about just some functions:
>> array_first(array, dim)
>> array_last(array, dim)
> You image these to return the actual element, not the first and last index value, right?
> Because we already have array_lower() and array_upper() which return the lower and upper
> index bound for a certain dimension.
> (
> A more general solution would be a function
> array_relative(array anyarray, indices int[])

I don't think so this design helps. instead maintaining a data array,
you should to maintain a indices array.


> which would return the element indexed by <indices>, where positive indices are assumed to
> be relative to the respective dimension's lower bound and negative indices to the
> upper bound + 1.
> For slices, we could additionally have
> array_relative(array anyarray, indices_start int[], indices_end int[])
> best regards,
> Florian Pflug
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:

In response to


pgsql-hackers by date

Next:From: Magnus HaganderDate: 2011-01-05 12:29:39
Subject: Re: We need to log aborted autovacuums
Previous:From: Itagaki TakahiroDate: 2011-01-05 11:37:25
Subject: Re: SQL/MED - core functionality

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group