Re: Variable substitution in psql backtick expansion

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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-26 16:40:05
Message-ID: alpine.DEB.2.20.1708261740590.17521@lancre
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers


Hello Tom,

>> I understand that you would prefer VERSION_NAME to show something like
>> "11devel, server 9.6.4"

> No, that's not what I said. I'm just complaining that as the patch stands
> it will set SERVER_NAME to "11.0", where I think it should say "11devel"
> (as of today).

Ok.

> [...]
> VERSION "PostgreSQL 11devel on ..."
> CLIENT_VERSION_NAME "11devel"
> CLIENT_VERSION_NUM 110000

This kind of inconsistencies is hard for human memory:-(

> or just leaving "CLIENT" implicit for all of these variables:
>
> VERSION "PostgreSQL 11devel on ..."
> VERSION_NAME "11devel"
> VERSION_NUM 110000

That is already what the patch does, because of the VERSION precedent.

> Robert seems to prefer the last of those, and that'd be fine with me.
> (Note that CLIENT is ambiguous anyway: does it mean psql itself, or
> libpq?)

Hmmm. Indeed.

>> SERVER_VERSION_NAME "9.6.4"
>> SERVER_VERSION_NUM 090604
>
> I'm on board with this, except I don't think we should have any leading
> zero in the numeric form. There are contexts where somebody might think
> that means octal.

Indeed. The implementation already does this, I just typed it without
checking.

So basically the only thing needed from Robert & you seems to change
"11.0" to "11devel", which is fine with me.

The attached v5 does that.

--
Fabien.

Attachment Content-Type Size
psql-version-num-5.patch text/x-diff 3.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Meskes 2017-08-26 16:44:29 Re: Build failure on thrips
Previous Message Tom Lane 2017-08-26 16:18:02 Re: Build failure on thrips