Re: Exposing PG_VERSION_NUM in pg_config
От | Jim Nasby |
---|---|
Тема | Re: Exposing PG_VERSION_NUM in pg_config |
Дата | |
Msg-id | 55146CD0.8080004@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Exposing PG_VERSION_NUM in pg_config (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
On 3/25/15 2:00 PM, Andres Freund wrote: > 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. Exactly; not every problem can be solved by make. I know I've had to futz with the output of "SELECT version()" in the past, and I think I've had to do the same with pg_config --version. -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: