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

From Julien Rouhaud
Subject Re: pgsql: Move scanint8() to numutils.c
Date
Msg-id 20220216154246.s2zbaakmzmurozvs@jrouhaud
Whole thread Raw
In response to Re: pgsql: Move scanint8() to numutils.c  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On Wed, Feb 16, 2022 at 08:24:31AM -0500, Robert Haas wrote:
> On Wed, Feb 16, 2022 at 6:09 AM Peter Eisentraut
> <peter.eisentraut@enterprisedb.com> wrote:
> > I don't think we have ever systematically release-noted backend API
> > changes.  I don't know whether that would be useful, but a complete
> > treatment would be a significant effort (speaking from experience of
> > porting the mentioned pglogical between major releases).
> 
> Personally, I don't think I would ever have used such a thing if it
> had existed, because looking through the git history seems more
> efficient to me. The release notes can be wrong or can fail to contain
> enough information to fix whatever issue I've encountered, but the
> offending commit always tells the real story. It sounds like Joe may
> feel differently which is fair enough; I can only speak to my own
> experience.

Agreed.  I have been maintaining extensions for quite some time and the commit
log (and possibly the referenced discussions) always contains everything needed
to fix whatever code is broken with all the important details.  I also try to
rebuild my extensions regularly against the current HEAD, so at the time the
release notes are written they wouldn't be of any use anyway.

The only reason I see to have something in the release notes would be to warn
about a problematic API change, which doesn't result in hard compilation
failure or something mostly immediate like that.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: adding 'zstd' as a compression algorithm
Next
From: Robert Haas
Date:
Subject: Re: refactoring basebackup.c (zstd)