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

From Andres Freund
Subject Re: Exposing PG_VERSION_NUM in pg_config
Date
Msg-id 20150325190010.GE451@alap3.anarazel.de
Whole thread Raw
In response to Re: Exposing PG_VERSION_NUM in pg_config  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Exposing PG_VERSION_NUM in pg_config
List pgsql-hackers
On 2015-03-25 14:50:44 -0400, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> > On 3/24/15 6:26 PM, Tom Lane wrote:
> >> 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.
> 
> > Why else would you want the version number other than to do some kind of 
> > comparison?
> 
> The question is why, if we supply the version number in a make variable,
> you would not just use that variable instead of having to do
> "$(shell $(PG_CONFIG) --something)".  The shell version adds new failure
> modes, removes none, and has no redeeming social value that I can see.

I think using the makefile is preferrable if you have the version
dependency in the makefile. But if you don't actually use make
(e.g. stuff not written in C) or you need the detection in configure or
something, it's different.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Exposing PG_VERSION_NUM in pg_config
Next
From: Ryan Pedela
Date:
Subject: Re: deparsing utility commands