Re: [HACKERS] Variable substitution in psql backtick expansion - Mailing list 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.
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers