From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Pavel Stehule <pavel(dot)stehule(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-08-25 22:09:36 |
Message-ID: | 13303.1503698976@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-08-25 22:22:03 | Re: Variable substitution in psql backtick expansion |
Previous Message | Tom Lane | 2017-08-25 21:37:32 | Re: [PATCH] Push limit to sort through a subquery |