Thread: Subscript expressions do not have to evaluate to integers
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/sql-expressions.html Description: Section 4.2.3. Subscripts of the documentation states: > Each subscript is itself an expression, which must yield an integer value. However, the following query works on Postgres 12.1 SELECT (ARRAY[1, 2, 3]::integer[])[1.5]; array ------- 2 I believe a more appropriate statement would acknowledge that at least some values undergo an explicit-style conversion to an integer.
On Wed, Jul 22, 2020 at 02:59:18AM +0000, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/12/sql-expressions.html > Description: > > Section 4.2.3. Subscripts of the documentation states: > > > Each subscript is itself an expression, which must yield an integer > value. > > However, the following query works on Postgres 12.1 > > SELECT (ARRAY[1, 2, 3]::integer[])[1.5]; > > array > ------- > 2 > > I believe a more appropriate statement would acknowledge that at least some > values undergo an explicit-style conversion to an integer. OK, how is the attached patch? -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Attachment
Bruce Momjian <bruce@momjian.us> writes:
> On Wed, Jul 22, 2020 at 02:59:18AM +0000, PG Doc comments form wrote:
>> I believe a more appropriate statement would acknowledge that at least some
>> values undergo an explicit-style conversion to an integer.
> OK, how is the attached patch?
"and" is not an improvement over "which". Otherwise seems OK.
(The proposed patch for generic subscripting will probably need to
rewrite this completely, but for now this is an improvement.)
regards, tom lane
On Fri, Aug 21, 2020 at 6:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Bruce Momjian <bruce@momjian.us> writes:
> On Wed, Jul 22, 2020 at 02:59:18AM +0000, PG Doc comments form wrote:
>> I believe a more appropriate statement would acknowledge that at least some
>> values undergo an explicit-style conversion to an integer.
> OK, how is the attached patch?
"and" is not an improvement over "which". Otherwise seems OK.
(The proposed patch for generic subscripting will probably need to
rewrite this completely, but for now this is an improvement.)
I was going to add that maybe we should link to the round(dp or numeric) function in the documentation and let it be explicit about the rounding rules pertaining to half - which when I look isn't actually documented:
round(dp or numeric) (same as input) round to nearest integer
Maybe everyone just knows that rounding, unless otherwise stated, rounds halves away from zero but it doesn't seem like a bad idea to be explicit.
David J.
On Fri, Aug 21, 2020 at 07:21:30PM -0700, David G. Johnston wrote: > On Fri, Aug 21, 2020 at 6:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Bruce Momjian <bruce@momjian.us> writes: > > On Wed, Jul 22, 2020 at 02:59:18AM +0000, PG Doc comments form wrote: > >> I believe a more appropriate statement would acknowledge that at least > some > >> values undergo an explicit-style conversion to an integer. > > > OK, how is the attached patch? > > "and" is not an improvement over "which". Otherwise seems OK. OK, done in the attached patch. > (The proposed patch for generic subscripting will probably need to > rewrite this completely, but for now this is an improvement.) > > > I was going to add that maybe we should link to the round(dp or numeric) > function in the documentation and let it be explicit about the rounding rules > pertaining to half - which when I look isn't actually documented: > > round(dp or numeric) (same as input) round to nearest integer > > Maybe everyone just knows that rounding, unless otherwise stated, rounds halves > away from zero but it doesn't seem like a bad idea to be explicit. I don't think we use round() directly, to I am hesitant to link to that, but your idea that we should mention we are rounding to the "nearest" integer, rather than floor or ceil is a good one, so I mentioned that in the attached updated patch. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Attachment
On Sat, Aug 22, 2020 at 8:47 AM Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Aug 21, 2020 at 07:21:30PM -0700, David G. Johnston wrote:
> On Fri, Aug 21, 2020 at 6:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Bruce Momjian <bruce@momjian.us> writes:
> > On Wed, Jul 22, 2020 at 02:59:18AM +0000, PG Doc comments form wrote:
> >> I believe a more appropriate statement would acknowledge that at least
> some
> >> values undergo an explicit-style conversion to an integer.
>
> > OK, how is the attached patch?
>
> "and" is not an improvement over "which". Otherwise seems OK.
OK, done in the attached patch.
Works for me.
David J.
On Sat, Aug 22, 2020 at 01:34:35PM -0700, David G. Johnston wrote: > On Sat, Aug 22, 2020 at 8:47 AM Bruce Momjian <bruce@momjian.us> wrote: > > On Fri, Aug 21, 2020 at 07:21:30PM -0700, David G. Johnston wrote: > > On Fri, Aug 21, 2020 at 6:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > Bruce Momjian <bruce@momjian.us> writes: > > > On Wed, Jul 22, 2020 at 02:59:18AM +0000, PG Doc comments form > wrote: > > >> I believe a more appropriate statement would acknowledge that at > least > > some > > >> values undergo an explicit-style conversion to an integer. > > > > > OK, how is the attached patch? > > > > "and" is not an improvement over "which". Otherwise seems OK. > > OK, done in the attached patch. > > > Works for me. Patch applied. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee