On Fri, Aug 25, 2017 at 6:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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).
If somebody's doing comparisons, they probably want the numeric
version, but somebody might want to print the string version in an
error message e.g. \if <test involving VERSION_NUM> \echo this thing
doesn't work on :VERSION_NAME \quit \endif
>> - 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.
OK, got it.
>> - 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.
Hmm, well I think that's probably a pretty good reason to stick with
the names in the proposed patch. VERSION seems like it was
shortsighted, but I think we're probably best off being consistent
with the precedent at this point.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company