From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Yury Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru> |
Subject: | Re: Possible marginally-incompatible change to array subscripting |
Date: | 2015-12-22 17:34:26 |
Message-ID: | CA+TgmoZXATVyKVxOtW4Z-tLoUEe6GKKxnGm8r1ywGNr8QQ9=Sw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 22, 2015 at 11:51 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm reviewing Yury Zhuravlev's patch to allow array slice boundaries to be
> omitted, for example "a[4:]" means "the slice extending from element 4 to
> the last element of a". It strikes me that there's an improvement we
> could easily make for the case where a mixture of slice and non-slice
> syntax appears, that is something like "a[3:4][5]". Now, this has always
> meant a slice, and the way we've traditionally managed that is to treat
> simple subscripts as being the range upper bound with a lower bound of 1;
> that is, what this example means is exactly "a[3:4][1:5]".
>
> ISTM that if we'd had Yury's code in there from the beginning, what we
> would define this as meaning is "a[3:4][:5]", ie the implied range runs
> from whatever the array lower bound is up to the specified subscript.
>
> This would make no difference of course for the common case where the
> array lower bound is 1, but it seems a lot less arbitrary when it isn't.
> So I think we should strongly consider changing it to mean that, even
> though it would be non-backwards-compatible in such cases.
>
> Comments?
Gosh, our arrays are strange. I would have expected a[3:4][5] to mean
a[3:4][5:5].
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-12-22 17:36:42 | Re: Foreign join pushdown vs EvalPlanQual |
Previous Message | Robert Haas | 2015-12-22 17:31:31 | Re: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates |