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

From Robert Haas
Subject Re: pgsql: Move scanint8() to numutils.c
Date
Msg-id CA+TgmobLY=ZcvD9cLnhA92ATnEfNHgfEDM4MUCsRADH9td+mrw@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Move scanint8() to numutils.c  (Joe Conway <mail@joeconway.com>)
Responses Re: pgsql: Move scanint8() to numutils.c  (Joe Conway <mail@joeconway.com>)
Re: pgsql: Move scanint8() to numutils.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.

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



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work
Next
From: Matthias van de Meent
Date:
Subject: Re: Lowering the ever-growing heap->pd_lower