Date: Sat, 22 Aug 2020 11:47:37 -0400
From: Bruce Momjian <bruce@momjian.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, sean@materialize.io,
	Pg Docs <pgsql-docs@lists.postgresql.org>
Subject: Re: Subscript expressions do not have to evaluate to integers
Message-ID: <20200822154737.GB26781@momjian.us>
References: <159538675800.624.7728794628229799531@wrigleys.postgresql.org>
 <20200822003331.GN13363@momjian.us>
 <2099092.1598059351@sss.pgh.pa.us>
 <CAKFQuwY_EtAVCRbu4HxDrHg1Wo0HMnD_uydFw=ZQzTMdDXDFqQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="i0/AhcQY5QxfSsSZ"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAKFQuwY_EtAVCRbu4HxDrHg1Wo0HMnD_uydFw=ZQzTMdDXDFqQ@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk


--i0/AhcQY5QxfSsSZ
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

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


--i0/AhcQY5QxfSsSZ
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="array.diff"

diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml
index 2f993ca2e0..f1e3402528 100644
--- a/doc/src/sgml/syntax.sgml
+++ b/doc/src/sgml/syntax.sgml
@@ -1378,7 +1378,7 @@ CREATE FUNCTION dept(text) RETURNS dept
 </synopsis>
     (Here, the brackets <literal>[ ]</literal> are meant to appear literally.)
     Each <replaceable>subscript</replaceable> is itself an expression,
-    which must yield an integer value.
+    which will be rounded to the nearest integer value.
    </para>
 
    <para>

--i0/AhcQY5QxfSsSZ--