Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing serverversion and psql version. - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing serverversion and psql version.
Date
Msg-id CANP8+jLGoZKRA-HT2yqfg4YJiPsJ+qe0aKTpGbNsntbz-396WQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.
Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing serverversion and psql version.
List pgsql-hackers
On 5 September 2017 at 09:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Sep 5, 2017 at 12:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Hm.  I think it would be a fine idea to push this change into v10,
>>> so that all psql versions that have \if would have these variables.
>>> However, I'm less enthused about adding them to the 9.x branches.
>>> Given the lack of \if, I'm not seeing a use-case that would justify
>>> taking any compatibility risk for.
>>>
>>> Opinions anyone?
>
>> As I see it, the risks of back-patching are:
>
>> 1. Different minor versions will have different behavior, and that
>> tends to create more problems than it solves.
>
> Yeah.  Whatever use-case you think might exist for these variables in,
> say, 9.6 is greatly weakened by the fact that releases through 9.6.5
> don't have them.

Makes sense

> However, since v10 is still in beta I don't think that argument
> applies to it.

OK


Does raise the further question of how psql behaves when we connect to
a pre-10 server, so we have SERVER_VERSION_NUM but yet it is not set.
How does this
\if SERVER_VERSION_NUM < x
behave if unset? Presumably it fails, even though the version *is* less than x
Do we need some macro or suggested special handling?

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan
Next
From: Jesper Pedersen
Date:
Subject: Re: [HACKERS] Fix performance of generic atomics