From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pavel Stehule <pavel.stehule@gmail.com>
cc: Fabien COELHO <coelho@cri.ensmp.fr>, Robert Haas <robertmhaas@gmail.com>,
        Corey Huinker <corey.huinker@gmail.com>,
        Daniel Verite <daniel@manitou-mail.org>,
        PostgreSQL Developers <pgsql-hackers@postgresql.org>
Subject: Re: Variable substitution in psql backtick expansion
In-reply-to: 
 <CAFj8pRAGwaZnDPPt5WqKw8wjgGBYDw2Zss+wBf5P-Mb9w2-NWw@mail.gmail.com>
References: <bc15034d-b421-42ac-89b1-c3485fa1728b@manitou-mail.org>
 <alpine.DEB.2.20.1704021805550.4632@lancre>
 <CADkLM=c+hm2rc0tkKgC-ZgrLttHT2KkfppE+BC-=i-xj+7V-TQ@mail.gmail.com>
 <3926.1491159242@sss.pgh.pa.us> <alpine.DEB.2.20.1704022151080.9265@lancre>
 <CAFj8pRDyaC+FaSxd92CLcuV+UFGhwY7NVVBhqFvxPkhvKNhyww@mail.gmail.com>
 <alpine.DEB.2.20.1705211737030.6053@lancre>
 <CA+TgmobT3rD6jaZMCs=PWH_khMu6Bb4TwX+r4tbTNA41hx32=w@mail.gmail.com>
 <13303.1503698976@sss.pgh.pa.us>
 <CA+TgmobXCcEM7uB8_g+tKfB-1gvEyp+Qmmre9bcXU9mgpmW38Q@mail.gmail.com>
 <14596.1503701034@sss.pgh.pa.us> <alpine.DEB.2.20.1708260747110.3627@lancre>
 <20786.1503760136@sss.pgh.pa.us> <alpine.DEB.2.20.1708261740590.17521@lancre>
 <24850.1503766425@sss.pgh.pa.us> <alpine.DEB.2.20.1708261959560.27500@lancre>
 <4959.1503774468@sss.pgh.pa.us> <alpine.DEB.2.20.1708270811060.18068@lancre>
 <2947.1504542679@sss.pgh.pa.us> <14258.1504557328@sss.pgh.pa.us>
 <alpine.DEB.2.20.1709042237230.19424@lancre> <CAFj8pRAGwaZnDPPt5WqKw8wjgG!
 BYDw2Zss+wBf5P-Mb9w2-NWw@mail.gmail.com>
Comments: In-reply-to Pavel Stehule <pavel.stehule@gmail.com>
	message dated "Fri, 10 Nov 2017 15:49:28 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23433.1510518105.1@sss.pgh.pa.us>
Date: Sun, 12 Nov 2017 15:21:45 -0500
Message-ID: <23434.1510518105@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Pavel Stehule <pavel.stehule@gmail.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.

			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