Re: [HACKERS] Variable substitution in psql backtick expansion - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] Variable substitution in psql backtick expansion
Date
Msg-id alpine.DEB.2.20.1709042237230.19424@lancre
Whole thread Raw
In response to Re: [HACKERS] Variable substitution in psql backtick expansion  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Variable substitution in psql backtick expansion
List pgsql-hackers
> I think we should go with Daniel's idea for all three parts.

I'm okay with that, although probably it should be an independent patch.

>> 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_*.
>
> I started with it that way, but it seemed pretty unreadable with the
> parenthetical examples added.  And I think we need the examples,
> particularly the one pointing out that you might get something like "beta".

Yes for "beta" which is also in the v8 patch I sent. One shared doc with 
different examples does not look too bad to me, and having things repeated 
so closely do not look good.

>> 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.
>
> The problem there is you can't get version() without an extra round trip
> to the server --- and an extra logged query --- which people are going to
> complain about.

Yep.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: [HACKERS] pgbench - minor fix for meta command only scripts
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] JIT compiling expressions/deform + inlining prototypev2.0