Re: [HACKERS] pg_config --version-num - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] pg_config --version-num
Date
Msg-id 31260.1496200053@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] pg_config --version-num  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [HACKERS] pg_config --version-num  ("David G. Johnston" <david.g.johnston@gmail.com>)
List 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 by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] Adding support for Default partition in partitioning
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Why does logical replication launcher setapplication_name?