Re: Variable substitution in psql backtick expansion

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Robert Haas <robertmhaas(at)gmail(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Variable substitution in psql backtick expansion
Date: 2017-11-13 01:06:40
Message-ID: CAB7nPqQwx21AjTaui1d217m=_7T7=shL69TjbQk5AHrH4g=7zQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 13, 2017 at 5:21 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> [ psql-server-version-2.patch ]
>
> I think this patch should be rejected. It adds no new functionality;
> you can get the string in question with "select version()". Moreover,
> you've been able to do that for lo these many years. Any application
> that tried to depend on this new way of getting the string would fail
> when working with an older server or older psql. That does not seem
> like a good property for a version check. Also, because the string
> isn't especially machine-friendly, it's not very clear to me what the
> use-case is for an application to use it at all, rather than the other
> version formats we already provide.

+1 for rejection as version() returns PG_VERSION_STR already. It is
also already possible to define a VERSION variable psqlrc simply with
that:
\set VERSION 'version();'

+-- check consistency of SERVER_VERSION
+-- which is transmitted as GUC "server_version_raw"
+SELECT :'SERVER_VERSION' = VERSION()
+ AND :'SERVER_VERSION' = current_setting('server_version_raw')
+ AND :'SERVER_VERSION' = :'VERSION'
+ AS "SERVER_VERSION is consistent";
Not much enthusiastic with this test when thinking about cross-upgrades.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2017-11-13 02:11:27 Re: Incorrect comment for build_child_join_rel
Previous Message Michael Paquier 2017-11-13 00:55:49 Re: PATCH: psql tab completion for SELECT