Re: pgsql: Move scanint8() to numutils.c - Mailing list pgsql-hackers

From Joe Conway
Subject Re: pgsql: Move scanint8() to numutils.c
Date
Msg-id 58cca3e9-53b8-e824-7cd4-6e59b4e242b1@joeconway.com
Whole thread Raw
Responses Re: pgsql: Move scanint8() to numutils.c  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2/14/22 16:18, Peter Eisentraut wrote:
> 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 <john.naylor@enterprisedb.com>
> Discussion: https://www.postgresql.org/message-id/flat/b239564c-cad0-b23e-c57e-166d883cb97d@enterprisedb.com

(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



pgsql-hackers by date:

Previous
From: walther@technowledgy.de
Date:
Subject: Re: [PATCH] Add reloption for views to enable RLS
Next
From: Andres Freund
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT