Re: Exposing PG_VERSION_NUM in pg_config

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Exposing PG_VERSION_NUM in pg_config
Дата
Msg-id 20150325190010.GE451@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Exposing PG_VERSION_NUM in pg_config  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Exposing PG_VERSION_NUM in pg_config  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Exposing PG_VERSION_NUM in pg_config
Следующее
От: Ryan Pedela
Дата:
Сообщение: Re: deparsing utility commands