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
-------
2I 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
Attachments:
array.difftext/x-diff; charset=us-asciiDownload+1-1
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
Attachments:
array.difftext/x-diff; charset=us-asciiDownload+1-1
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 formwrote:
� � �>> 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