Re: pgsql: Move scanint8() to numutils.c
От | Julien Rouhaud |
---|---|
Тема | Re: pgsql: Move scanint8() to numutils.c |
Дата | |
Msg-id | 20220216154246.s2zbaakmzmurozvs@jrouhaud обсуждение исходный текст |
Ответ на | Re: pgsql: Move scanint8() to numutils.c (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: