Re: [HACKERS] pg_config --version-num
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] pg_config --version-num |
| Дата | |
| Msg-id | 31260.1496200053@sss.pgh.pa.us обсуждение |
| Ответ на | Re: [HACKERS] pg_config --version-num (Craig Ringer <craig@2ndquadrant.com>) |
| Ответы |
Re: [HACKERS] pg_config --version-num
|
| Список | pgsql-hackers |
Craig Ringer <craig@2ndquadrant.com> writes:
> On 31 May 2017 9:36 am, "Michael Paquier" <michael.paquier@gmail.com> wrote:
>> Is the data in Makefile.global unsufficient?
> It's a pain in the butt because then you need to find or get passed the
> name of Makefile.global. Then you have to template it out into a file. Or
> parse the Makefile. Or create a wrapper program to emit it.
> It's beyond me why we don't expose this at runtime for use in scripts and
> tools. (Then again, the same is true of reporting it in the startup message
> and we know how that's gone).
Hm, but with this you're trading that problem for "is the right version
of pg_config in my PATH?". I can't see using this in TAP testing, for
instance, because it would never work in "make check" scenarios.
This idea might well be useful for external packages which are always
built/tested against installed versions of Postgres. But it seems like
we need to think harder about what to do for our own usages, and that
may lead to a different solution altogether.
regards, tom lane
В списке pgsql-hackers по дате отправления: