[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config
From:       Peter Eisentraut <peter_e () gmx ! net>
Date:       2015-03-31 23:50:51
Message-ID: 551B32DB.6030707 () gmx ! net
[Download RAW message or body]

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?


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread]