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

From Tom Lane
Subject Re: Exposing PG_VERSION_NUM in pg_config
Date
Msg-id 11298.1427239578@sss.pgh.pa.us
Whole thread Raw
In response to Re: Exposing PG_VERSION_NUM in pg_config  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Exposing PG_VERSION_NUM in pg_config  (David Fetter <david@fetter.org>)
Re: Exposing PG_VERSION_NUM in pg_config  (Michael Paquier <michael.paquier@gmail.com>)
Re: Exposing PG_VERSION_NUM in pg_config  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> I concur with Michael that there's value in exposing the version
>  Tom> number in the numeric form used by PG_VERSION_NUM.  However, I
>  Tom> also concur with Andrew that if the use-case for this is
>  Tom> Makefiles, pg_config is a pretty poor transmission mechanism.  We
>  Tom> should instead add PG_VERSION_NUM to the version variables set in
>  Tom> Makefile.global.

> I think there's an argument for both. pg_config already has a VERSION=
> string in the output, and I think adding a VERSION_NUM= would be good
> for consistency there. And people definitely do want to do version
> comparisons in makefiles...

Hm.  We're all agreed that there's a use case for exposing PG_VERSION_NUM
to the makefiles, but I did not hear one for adding it to pg_config; and
doing the former takes about two lines whereas adding a pg_config option
entails quite a lot of overhead (documentation, translatable help text,
yadda yadda).  So I'm not in favor of doing the latter without a much
more solid case than has been made.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: proposal: plpgsql - Assert statement
Next
From: Bruce Momjian
Date:
Subject: Re: NUMERIC private methods?