Re: Exposing PG_VERSION_NUM in pg_config - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Exposing PG_VERSION_NUM in pg_config
Date
Msg-id CAB7nPqRCA3k7X-MhHbZjE7fORC1dmzjpZSMv3Qgq0CVQM0aSLA@mail.gmail.com
Whole thread
In response to Re: Exposing PG_VERSION_NUM in pg_config  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Exposing PG_VERSION_NUM in pg_config
Re: Exposing PG_VERSION_NUM in pg_config
List pgsql-hackers


On Wed, Apr 1, 2015 at 8:50 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 3/31/15 1:05 AM, Michael Paquier wrote:
>
>
> On Tue, Mar 31, 2015 at 9:40 AM, Peter Eisentraut <peter_e@gmx.net
> <mailto:peter_e@gmx.net>> wrote:
>
>     On 3/30/15 6:29 PM, Michael Paquier wrote:
>     >
>     >
>     > On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut <peter_e@gmx.net <mailto:peter_e@gmx.net>
>     > <mailto:peter_e@gmx.net <mailto:peter_e@gmx.net>>> wrote:
>     >
>     >     On 3/25/15 1:32 AM, Michael Paquier wrote:
>     >     > Well, I have no other cases than ones of the type mentioned upthread,
>     >     > and honestly I am fine as long as we do not apply maths to a version
>     >     > string. So attached is a patch that adds VERSION_NUM in
>     >     > Makefile.global.
>     >
>     >     How would you make use of this in an extension makefile?
>     >
>     >
>     > One use case is regression test list filtering depending on backend version.
>
>     I'm interested in the exact syntax you'd use, to compare it to the
>     currently used techniques.
>
>
> With the presence of VERSION_NUM directly in pg_config, the following
> expression:
> VERSION_NUM=$(shell $(PG_CONFIG) --version-num)

My question is, once you have this version number in a variable like
VERSION_NUM, what specifically would you do with it?

For an extension that has a single branch compatible with a set of multiple major versions of Postgres, the cases are custom values for REGRESS_OPTS and REGRESS depending on the backend version. I also manipulate on a daily basis the same set of scripts across many platforms (on Windows as well using msysgit, and MSVC installation does not have pgxs stuff), so I would use it to simplify them. It is true that you can already do that by parsing the output of "pg_config --version", and that I would need to maintain both versions for some time (custom parsing of pg_config --version, and use of --version-num if this patch is accepted) but it looks IMO tempting to have directly the version number thinking long term if there is a simple integer number available at hand to identify a given version of PG.
--
Michael

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Exposing PG_VERSION_NUM in pg_config
Next
From: Tom Lane
Date:
Subject: Something is rotten in the state of Denmark...