From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Fabien COELHO <coelho@cri.ensmp.fr>,
        Pavel Stehule <pavel.stehule@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: 
 <CA+TgmobT3rD6jaZMCs=PWH_khMu6Bb4TwX+r4tbTNA41hx32=w@mail.gmail.com>
References: <bc15034d-b421-42ac-89b1-c3485fa1728b@manitou-mail.org>
 <alpine.DEB.2.20.1704020841490.4632@lancre>
 <CAFj8pRDCfLLNfMyNAjDwgHXS7inThdqgCaSbfKpiYXkb6Mvmwg@mail.gmail.com>
 <alpine.DEB.2.20.1704020917220.4632@lancre>
 <CAFj8pRCVFp+68Tt29sZfn9tE28c2D7u_VzTcXrqjyCVBzAzRsA@mail.gmail.com>
 <alpine.DEB.2.20.1704021303300.4632@lancre>
 <CAFj8pRACH1M=egydH4dAAoo9rRVTkuYCaoyZQK2Yf4BTQuRM5w@mail.gmail.com>
 <CADkLM=dzsbgJdP7KAJnbihxU1XFnWZgit9ye5cWnvkjZXyPbGw@mail.gmail.com>
 <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>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Fri, 25 Aug 2017 16:30:58 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13302.1503698976.1@sss.pgh.pa.us>
Date: Fri, 25 Aug 2017 18:09:36 -0400
Message-ID: <13303.1503698976@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Robert Haas <robertmhaas@gmail.com> writes:
> I am attempting to understand the status of this patch.  It looks like
> the patch that was the original subject of this thread was committed
> as f833c847b8fa4782efab45c8371d3cee64292d9b on April 1st by Tom, who
> was its author. Subsequently, a new patch not obviously related to the
> subject line was proposed by Fabien Coelho, and that patch was
> subsequently marked Ready for Committer by Pavel Stehule.  Meanwhile,
> objections were raised by Tom, who seems to think that we should make
> \if accept an expression language before we consider this change.

My question was more about how much of a use-case there is for these
values if there's no expression language yet.  On reflection though,
you can use either expr-in-backticks or a server query to make
comparisons, so there's at least some use-case for the numeric
versions today.  I'm still not sure that there's any use case for the
string versions ("9.6.4" etc).

> - Is it a good idea/practical to prevent the new variables from being
> modified by the user?

We haven't done that for existing informational variables, only control
variables that affect psql's behavior.  I think we should continue that
policy for new informational variables.  If we make them read-only, we
risk breaking scripts that are using those names for their own purposes.
If we don't make them read-only, we risk breaking scripts that are using
those names for their own purposes AND expecting them to provide the
built-in values.  The latter risk seems strictly smaller, probably much
smaller.

> - I think Pavel's upthread suggestion of prefixing the client
> variables with "client" to match the way the server variables are
> named is a good idea.

Well, the issue is the precedent of VERSION for the long-form string
spelling of psql's version.  But I agree that's not a very nice
precedent.  No strong opinion here.

			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