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-09-04 20:13:28 |
Message-ID: | alpine.DEB.2.20.1709042116020.16641@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Tom,
> So I thought we were done bikeshedding the variable names for this
> feature, but as I was reviewing the patch with intent to commit,
> I noticed you hadn't updated helpVariables() to mention them.
Indeed.
> Possibly you missed this because it doesn't mention VERSION either,
> but that doesn't seem very defensible.
Long time ago. Maybe I greped for it to check where it was appearing and
did not find what does not exist...
> I inserted text to describe all five variables --- but
> "SERVER_VERSION_NAME" is too long to fit in the available column space.
Indeed.
> In the attached updated patch, I moved all the descriptive text over one
> column, and really should have moved it over two columns; but adding even
> one space makes a couple of the lines longer than 80 columns when they
> were not before. Since we've blown past 80 columns on some of the other
> output, maybe that doesn't matter. Or maybe we should shorten this
> variable name so it doesn't force reformatting of all this text.
It seems that PSQL_EDITOR_LINENUMBER_ARG (25 characters) has been accepted
before for an environment variable.
> Possible ideas include "DB_VERSION_NAME", "SERVER_VER_NAME", or
> "SERVER_VERSION_STR". (The last saves only one character, whereas
> we really need to save two if we're trying not to be wider than any
> other documented variable.)
>
> Thoughts?
Like Pavel, I must admit that I do not like these options much, nor the
other ones down thread: I hate "hungarian" naming, ISTM that mixing abbrev
and full words is better avoided. These are really minor aethetical
preferences that I may break occasionally, eg with _NUM for the nice
similarity with _NAME.
ISTM that it needs to be consistent with the pre-existing VERSION, which
rules out "VER".
Now if this is a bloker, I think that anything is more useful than no
variable as it is useful to have them for simple scripting test through
server side expressions.
I also like Daniel's idea to update formatting rules, eg following what is
done for environment variables and accepting that it won't fit in one page
anyway.
SERVER_VERSION NAME
bla bla bla
> Attached updated patch changes helpVariables() as we'd need to do if
> not renaming, and does some minor doc/comment wordsmithing elsewhere.
Given my broken English, I'm fine with wordsmithing.
I like trying to keep the 80 (or 88 it seems) columns limit if possible,
because my getting older eyes water on long lines.
In the documentation, I do not think that both SERVER_VERSION_NAME and
_NUM (or whatever their chosen name) deserve two independent explanations
with heavy repeats just one after the other, and being treated differently
from VERSION_*.
The same together-ness approach can be used for helpVariables(), see v8
attached for instance.
Seeing it as is, it calls for having "SERVER_VERSION" as well, but I'm not
sure of the better way to get it. I tried with "SELECT VERSION() AS
SERVER_VERSION \gset" but varnames are lowerized.
--
Fabien.
Attachment | Content-Type | Size |
---|---|---|
psql-version-num-8.patch | text/x-diff | 5.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-09-04 20:26:09 | Re: pgbench tap tests & minor fixes. |
Previous Message | Tom Lane | 2017-09-04 19:41:22 | Re: pgbench tap tests & minor fixes. |