From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Remove win32ver.rc from version_stamp.pl
In-reply-to: <1ee46ac4-a9b2-4531-bf54-5ec2e374634d@2ndquadrant.com>
References: <1ee46ac4-a9b2-4531-bf54-5ec2e374634d@2ndquadrant.com>
Comments: In-reply-to Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
	message dated "Mon, 24 Feb 2020 09:02:02 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10988.1583103086.1@sss.pgh.pa.us>
Date: Sun, 01 Mar 2020 17:51:26 -0500
Message-ID: <10989.1583103086@sss.pgh.pa.us>
Precedence: bulk

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