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 77f5b16f-cabd-e7e2-db9e-e3e41ff8eec6@joeconway.com
Whole thread Raw
In response to Re: pgsql: Move scanint8() to numutils.c  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pgsql: Move scanint8() to numutils.c  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
On 2/15/22 13:47, Robert Haas wrote:
> On Tue, Feb 15, 2022 at 10:39 AM Joe Conway <mail@joeconway.com> wrote:
>> (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.
> 
> 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.


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

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



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: adding 'zstd' as a compression algorithm
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Move scanint8() to numutils.c