Re: Exposing PG_VERSION_NUM in pg_config

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Exposing PG_VERSION_NUM in pg_config
Дата
Msg-id CAFj8pRDOA4hoqM3eCsDFxobUS4SDH0ZuBTMcX-x_dj==i5HV9Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Exposing PG_VERSION_NUM in pg_config  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Exposing PG_VERSION_NUM in pg_config
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?