Subject: pgsql: Move scanint8() to numutils.c

From: Peter Eisentraut <[email-masked]>
Date: Mon, 14 Feb 2022 21:18:04 +0000

Move scanint8() to numutils.c

Move scanint8() to numutils.c and rename to pg_strtoint64().  We
already have a "16" and "32" version of that, and the code inside the
functions was aligned, so this move makes all three versions
consistent.  The API is also changed to no longer provide the errorOK
case.  Users that need the error checking can use strtoi64().

Reviewed-by: John Naylor <[email-masked]>
Discussion: https://www.postgresql.org/message-id/flat/[email-masked]

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/cfc7191dfea330dd7a71e940d59de78129bb6175

Modified Files
--------------
src/backend/parser/parse_node.c             | 12 +++-
src/backend/replication/pgoutput/pgoutput.c | 10 ++--
src/backend/utils/adt/int8.c                | 90 +----------------------------
src/backend/utils/adt/numutils.c            | 84 +++++++++++++++++++++++++++
src/bin/pgbench/pgbench.c                   |  4 +-
src/include/utils/builtins.h                |  1 +
src/include/utils/int8.h                    | 25 --------
7 files changed, 104 insertions(+), 122 deletions(-)

---

From: Joe Conway <[email-masked]>
Date: Tue, 15 Feb 2022 10:39:34 -0500

> Discussion: https://www.postgresql.org/message-id/flat/[email-masked]

(moving to hackers)

I guess shame on me for not noticing the thread, but I don't see any 
discussion about the potential for breakage to external projects.

scanint8() is exported, and this change breaks at least two extensions I 
maintain.

A quick scan (no pun intended ;-)) of github shows other potential 
breakage, including at least older (still open source) versions of 
pglogical.

Joe
-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

---

From: Robert Haas <[email-masked]>
Date: Tue, 15 Feb 2022 13:47:26 -0500

> breakage, including at least older (still open source) versions of

I don't have a particularly strong view on whether the underlying
change was a good idea here, but the breakage you're talking about
seems pretty easy to fix, unless I'm missing something? I think it
would be a bad idea to make such a change in a minor release without
concern for extension breakage, but in a new major release it doesn't
seem like a problem to me.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

---

From: Joe Conway <[email-masked]>
Date: Tue, 15 Feb 2022 14:00:04 -0500

> seem like a problem to me.

I'm not saying it is hard to fix, but it seems a bit cavalier to not 
even discuss the potential for breakage. If nothing else we should flag 
this as something for the release notes.

Joe

---

From: Tom Lane <[email-masked]>
Date: Tue, 15 Feb 2022 14:05:19 -0500

> seem like a problem to me.

Yeah, this seems well within our expectations for major-release
changes.

			regards, tom lane