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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 +--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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