Thread: Remove win32ver.rc from version_stamp.pl
This removes another relic from the old nmake-based Windows build. version_stamp.pl put version number information into win32ver.rc. But win32ver.rc already gets other version number information from the preprocessor at build time, so it would make more sense if all version number information would be handled in the same way and we don't have two places that do it. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> This removes another relic from the old nmake-based Windows build.
> version_stamp.pl put version number information into win32ver.rc. But
> win32ver.rc already gets other version number information from the
> preprocessor at build time, so it would make more sense if all version
> number information would be handled in the same way and we don't have
> two places that do it.
This has a minor conflict in Solution.pm according to the cfbot.
In general, while I'm on board with the idea, I wonder whether it
wouldn't be smarter to keep on defining PG_MAJORVERSION as a string,
and just add PG_MAJORVERSION_NUM alongside of it. This would
eliminate some hunks from the patch in places where it's more
convenient to have the version as a string, and it would avoid
what could otherwise be a pretty painful cross-version incompatibility
for extensions. We already provide PG_VERSION in both forms, so
I don't see any inconsistency in doing likewise for PG_MAJORVERSION.
regards, tom lane
On 2020-03-01 23:51, Tom Lane wrote: > In general, while I'm on board with the idea, I wonder whether it > wouldn't be smarter to keep on defining PG_MAJORVERSION as a string, > and just add PG_MAJORVERSION_NUM alongside of it. This would > eliminate some hunks from the patch in places where it's more > convenient to have the version as a string, and it would avoid > what could otherwise be a pretty painful cross-version incompatibility > for extensions. We already provide PG_VERSION in both forms, so > I don't see any inconsistency in doing likewise for PG_MAJORVERSION. Agreed. Here is another patch. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-03-01 23:51, Tom Lane wrote:
>> In general, while I'm on board with the idea, I wonder whether it
>> wouldn't be smarter to keep on defining PG_MAJORVERSION as a string,
>> and just add PG_MAJORVERSION_NUM alongside of it.
> Agreed. Here is another patch.
This version LGTM. (I can't actually test the Windows aspects
of this, but I assume you did.)
I'm wondering a little bit whether it'd be worth back-patching the
additions of the new #defines. That would cut about five years off
the time till they could be relied on by extensions. However,
I'm not sure anyone is eager to rely on them, so it may not be
worth the effort.
regards, tom lane
On 2020-03-09 15:55, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> On 2020-03-01 23:51, Tom Lane wrote: >>> In general, while I'm on board with the idea, I wonder whether it >>> wouldn't be smarter to keep on defining PG_MAJORVERSION as a string, >>> and just add PG_MAJORVERSION_NUM alongside of it. > >> Agreed. Here is another patch. > > This version LGTM. (I can't actually test the Windows aspects > of this, but I assume you did.) committed > I'm wondering a little bit whether it'd be worth back-patching the > additions of the new #defines. That would cut about five years off > the time till they could be relied on by extensions. However, > I'm not sure anyone is eager to rely on them, so it may not be > worth the effort. I doubt external code really needs these symbols. You can always use PG_VERSION_NUM. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services