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
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 |