Обсуждение: documentation describing the range of a number type 'integer' is incorrect

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/13/datatype-numeric.html
Description:

https://www.postgresql.org/docs/13/datatype-numeric.html says that the range
of a numeric type integer is -2147483648 to +2147483647 but
PGTYPESnumeric_to_int considers -2147483648 (a perfectly valid 32-bit
integer) to be invalid because it compares to -INT_MAX instead of INT_MIN or
(-INT_MAX - 1). This goes back to the initial commit in the git repo for
src/interfaces/ecpg/pgtypeslib/numeric.c. And doc/src/sgml/ecpg.sgml
documents the min being -INT_MAX.

On 2021-Jul-29, PG Doc comments form wrote:

> https://www.postgresql.org/docs/13/datatype-numeric.html says that the range
> of a numeric type integer is -2147483648 to +2147483647 but
> PGTYPESnumeric_to_int considers -2147483648 (a perfectly valid 32-bit
> integer) to be invalid because it compares to -INT_MAX instead of INT_MIN or
> (-INT_MAX - 1). This goes back to the initial commit in the git repo for
> src/interfaces/ecpg/pgtypeslib/numeric.c. And doc/src/sgml/ecpg.sgml
> documents the min being -INT_MAX.

This sounds like an ECPG bug, not a documentation problem.

-- 
Álvaro Herrera           39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/
"XML!" Exclaimed C++.  "What are you doing here? You're not a programming
language."
"Tell that to the people who use me," said XML.
https://burningbird.net/the-parable-of-the-languages/

On 2021-Oct-22, Kevin Sweet wrote:

>    The bugs team agreed that it's a bug. The documentation accurately
>    represents the buggy code. I thought you might want to update the doc
>    when the bug is fixed.

It looks like the bug and the docs have both been fixed for months.  I
just somehow failed to realize that I was replying to such an old message.
Sorry for the noise.

https://postgr.es/m/17128-55a8a879727a3e3a@postgresql.org

-- 
Álvaro Herrera           39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/
"The Gord often wonders why people threaten never to come back after they've
been told never to return" (www.actsofgord.com)

On Fri, Oct 22, 2021 at 11:55:33AM -0700, Kevin Sweet wrote:
> The bugs team agreed that it's a bug. The documentation accurately represents
> the buggy code. I thought you might want to update the doc when the bug is
> fixed.

This was fixed in this commit:

    commit 5fcf3945bd
    Author: John Naylor <john.naylor@postgresql.org>
    Date:   Fri Jul 30 13:50:23 2021 -0400
    
        Fix range check in ECPG numeric to int conversion
    
        The previous coding guarded against -INT_MAX instead of INT_MIN,
        leading to -2147483648 being rejected as out of range.
    
        Per bug #17128 from Kevin Sweet
    
        Discussion: https://www.postgresql.org/message-id/flat/17128-55a8a879727a3e3a%40postgresql.org
        Reviewed-by: Tom Lane
        Backpatch to all supported branches

This was backpatched to all branches, so any release after July 30, 2021
should have this fix.  I don't see any docs that need adjusting.

---------------------------------------------------------------------------

> 
> 
> On 10/22/21 6:43 AM, Alvaro Herrera wrote:
> 
>     On 2021-Jul-29, PG Doc comments form wrote:
> 
> 
>         https://www.postgresql.org/docs/13/datatype-numeric.html says that the range
>         of a numeric type integer is -2147483648 to +2147483647 but
>         PGTYPESnumeric_to_int considers -2147483648 (a perfectly valid 32-bit
>         integer) to be invalid because it compares to -INT_MAX instead of INT_MIN or
>         (-INT_MAX - 1). This goes back to the initial commit in the git repo for
>         src/interfaces/ecpg/pgtypeslib/numeric.c. And doc/src/sgml/ecpg.sgml
>         documents the min being -INT_MAX.
> 
>     This sounds like an ECPG bug, not a documentation problem.
> 
> 
> 

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Indecision is a decision.  Inaction is an action.  Mark Batterson