Thread: [HACKERS] tupconvert.c API change in v10 release notes
FYI, I happened across this commit comment: 3f902354b08ac788600f0ae54fcbfc1d4e3ea765 | So, let's accept the removal of the guarantee about | the output tuple's rowtype marking, recognizing that this is a API change | that could conceivably break third-party callers of tupconvert.c. (So, | let's remember to mention it in the v10 release notes.) ..but couldn't see that the commit or change is so referenced. Justin
Justin Pryzby <pryzby@telsasoft.com> writes:
> FYI, I happened across this commit comment:
> 3f902354b08ac788600f0ae54fcbfc1d4e3ea765
> | So, let's accept the removal of the guarantee about
> | the output tuple's rowtype marking, recognizing that this is a API change
> | that could conceivably break third-party callers of tupconvert.c. (So,
> | let's remember to mention it in the v10 release notes.)
> ..but couldn't see that the commit or change is so referenced.
Yeah, I see nothing about 3f902354b in release-10.sgml either.
We've had varying policies over the years about whether to mention
internal API changes in the release notes or not, but this one
I think does belong there, since it's a silent API break rather
than one that would easily be caught due to compiler errors.
Bruce, did you have any specific reasoning for leaving it out?
regards, tom lane
On Wed, Jul 19, 2017 at 12:39:07PM -0400, Tom Lane wrote: > Justin Pryzby <pryzby@telsasoft.com> writes: > > FYI, I happened across this commit comment: > > 3f902354b08ac788600f0ae54fcbfc1d4e3ea765 > > | So, let's accept the removal of the guarantee about > > | the output tuple's rowtype marking, recognizing that this is a API change > > | that could conceivably break third-party callers of tupconvert.c. (So, > > | let's remember to mention it in the v10 release notes.) > > > ..but couldn't see that the commit or change is so referenced. > > Yeah, I see nothing about 3f902354b in release-10.sgml either. > We've had varying policies over the years about whether to mention > internal API changes in the release notes or not, but this one > I think does belong there, since it's a silent API break rather > than one that would easily be caught due to compiler errors. > Bruce, did you have any specific reasoning for leaving it out? I doubt I saw that sentence in the paragraph. For long text like that, I am usually looking for "BACKWARDS INCOMPATIBLE CHANGE" or something like that. Sorry I missed it. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bruce Momjian <bruce@momjian.us> writes:
> On Wed, Jul 19, 2017 at 12:39:07PM -0400, Tom Lane wrote:
>> Yeah, I see nothing about 3f902354b in release-10.sgml either.
>> We've had varying policies over the years about whether to mention
>> internal API changes in the release notes or not, but this one
>> I think does belong there, since it's a silent API break rather
>> than one that would easily be caught due to compiler errors.
>> Bruce, did you have any specific reasoning for leaving it out?
> I doubt I saw that sentence in the paragraph. For long text like that,
> I am usually looking for "BACKWARDS INCOMPATIBLE CHANGE" or something
> like that. Sorry I missed it.
I added something about this to the notes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers