Re: Exposing PG_VERSION_NUM in pg_config - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Exposing PG_VERSION_NUM in pg_config
Date
Msg-id CAFj8pRDOA4hoqM3eCsDFxobUS4SDH0ZuBTMcX-x_dj==i5HV9Q@mail.gmail.com
Whole thread Raw
In response to Re: Exposing PG_VERSION_NUM in pg_config  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


2015-07-05 16:51 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
Michael Paquier <michael.paquier@gmail.com> writes:
> On Fri, Jul 3, 2015 at 6:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Michael Paquier <michael.paquier@gmail.com> writes:
>>> ... So attached is a patch that adds VERSION_NUM in
>>> Makefile.global.

>> While there was not exactly universal consensus that we need this, the
>> patch as given is merely two lines, so it seems awfully cheap to Just
>> Do It.  Hence, I've gone ahead and committed it.  If we start getting
>> complaints about use-cases this doesn't cover, we can re-discuss whether
>> it's worth doing more.

> This looks fine to me. Thanks.

After further thought I started wondering why I hadn't back-patched this.
It's certainly safe/trivial enough for back-patching.  If we leave it just
in HEAD, then extension authors wouldn't be able to use it in the intended
way until 9.5 is old enough that they don't care about supporting 9.5.x
anymore; which is perhaps 5 years away.  If we back-patch all supported
branches then it would be safe to rely on VERSION_NUM for building
extensions within a year or two.

Any objections to doing that?

+1

Pavel
 

                        regards, tom lane


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Exposing PG_VERSION_NUM in pg_config
Next
From: Andres Freund
Date:
Subject: Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?