From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Regina Obe <lr(at)pcorp(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL Version 10, missing minor version |
Date: | 2016-08-29 03:41:00 |
Message-ID: | CAMsr+YHPGq0HjqZ47ynSxO0LSPmmRgtSwCH8qVKAWbpogfgvYQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 29 August 2016 at 02:52, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Regina Obe" <lr(at)pcorp(dot)us> writes:
>> The routine in PostGIS to parse out the version number from pg_config is
>> breaking in the 10 cycle
>
> TBH, I wonder why you are doing that in the first place; it does not
> seem like the most reliable source of version information. If you
> need to do compile-time tests, PG_CATALOG_VERSION is considered the
> best thing to look at, or VERSION_NUM in Makefiles.
This is my cue to pop up and say that if you're looking at the startup
message you have to use the version string, despite it not being the
most reliable source of information, because we don't send
server_version_num ;)
Patch attached. Yes, I know PostGIS doesn't use it, but it makes no
sense to tell people not to parse the server version out in some
situations then force them to in others.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachment | Content-Type | Size |
---|---|---|
0001-Report-server_version_num-alongside-server_version-i.patch | text/x-patch | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-08-29 03:45:14 | Re: [PATCH] Transaction traceability - txid_status(bigint) |
Previous Message | Craig Ringer | 2016-08-29 03:25:39 | Re: [PATCH] Transaction traceability - txid_status(bigint) |