Re: pg_config --version-num

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_config --version-num
Date: 2017-05-31 03:07:33
Message-ID: 31260.1496200053@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> On 31 May 2017 9:36 am, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-05-31 03:10:31 Re: Why does logical replication launcher set application_name?
Previous Message Amit Langote 2017-05-31 02:43:20 Re: Adding support for Default partition in partitioning