Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Tom & Michaël, I think this patch should be rejected. +1 for rejection [...] The noes have it! Note that the motivation was really symmetric completion: fabien=# \echo :VERSION_NAME 11devel fabien=# \echo :VERSION_NUM 11 fabien=# \echo :VERSION PostgreSQL 11devel on

Re: [HACKERS] Variable substitution in psql backtick expansion

On Mon, Nov 13, 2017 at 5:21 AM, Tom Lane wrote: > Pavel Stehule writes: >> [ psql-server-version-2.patch ] > > I think this patch should be rejected. It adds no new functionality; > you can get the string in question with "select version()".

Re: [HACKERS] Variable substitution in psql backtick expansion

Pavel Stehule writes: > [ psql-server-version-2.patch ] I think this patch should be rejected. It adds no new functionality; you can get the string in question with "select version()". Moreover, you've been able to do that for lo these many years. Any application that

Re: [HACKERS] Variable substitution in psql backtick expansion

Hi I am sending a review of last patch psql-server-version-1.patch.gz This patch is trivial - the most big problem is choosing correct name for GUC. I am thinking so server_version_raw is acceptable. I had to fix doc - see attached updated patch All tests passed. I'll mark this patch as ready

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Gerdan, This is an internal address that should not be exposed: postgresql@coelho.net I'm unsure why it gets substituted by the "commitfest application"... When i try apply this patch he failed with a following messenger: It just worked for me on head with git

Re: [HACKERS] Variable substitution in psql backtick expansion

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:tested, passed When i try apply this patch he failed with a following messenger: File

Re: [HACKERS] Variable substitution in psql backtick expansion

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

Re: [HACKERS] Variable substitution in psql backtick expansion

[ psql-version-num-8.patch ] Pushed with some minor additional fiddling. Ok, Thanks. I also noticed the reformating. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Variable substitution in psql backtick expansion

I wrote: > "Daniel Verite" writes: >> That would look like the following, for example, with a 3-space margin >> for the description: >> AUTOCOMMIT >>If set, successful SQL commands are automatically committed > But we could do something close to that, say two-space

Re: [HACKERS] Variable substitution in psql backtick expansion

Fabien COELHO writes: > [ psql-version-num-8.patch ] Pushed with some minor additional fiddling. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Variable substitution in psql backtick expansion

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

Re: [HACKERS] Variable substitution in psql backtick expansion

Fabien COELHO writes: > 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. Yeah. When you look at all three portions of the helpVariables output, it's clear that

Re: [HACKERS] Variable substitution in psql backtick expansion

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

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-09-04 19:35 GMT+02:00 Tom Lane : > "Daniel Verite" writes: > > The two-space left margin on the entire block does not add that > > much to readability, IMV, so maybe we could reclaim these > > two characters. > > Well, it's a sub-list of the

Re: [HACKERS] Variable substitution in psql backtick expansion

"Daniel Verite" writes: > The two-space left margin on the entire block does not add that > much to readability, IMV, so maybe we could reclaim these > two characters. Well, it's a sub-list of the entire output of helpVariables(), so I think some indentation is a good

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-09-04 19:08 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > 2017-09-04 18:56 GMT+02:00 Tom Lane : > >> Just had another idea: maybe make the new variable names > >> SERVER_VERSION_S > >> SERVER_VERSION_N > >> VERSION_S > >>

Re: [HACKERS] Variable substitution in psql backtick expansion

Tom Lane wrote: > 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. The two-space left margin on the entire block does not add that much to

Re: [HACKERS] Variable substitution in psql backtick expansion

Pavel Stehule writes: > 2017-09-04 18:56 GMT+02:00 Tom Lane : >> Just had another idea: maybe make the new variable names >> SERVER_VERSION_S >> SERVER_VERSION_N >> VERSION_S >> VERSION_N > SERVER_VERSION_STR looks better than this. I dunno, I'm not

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-09-04 18:56 GMT+02:00 Tom Lane : > I wrote: > > ... Or maybe we should shorten this > > variable name so it doesn't force reformatting of all this text. > > Possible ideas include "DB_VERSION_NAME", "SERVER_VER_NAME", or > > "SERVER_VERSION_STR". (The last saves only one

Re: [HACKERS] Variable substitution in psql backtick expansion

Hi 2017-09-04 18:31 GMT+02:00 Tom Lane : > 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. > Possibly you missed this because

Re: [HACKERS] Variable substitution in psql backtick expansion

I wrote: > ... Or maybe we should shorten this > variable name so it doesn't force reformatting of all this text. > 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

Re: [HACKERS] Variable substitution in psql backtick expansion

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. Possibly you missed this because it doesn't mention VERSION either, but that doesn't seem very

Re: [HACKERS] Variable substitution in psql backtick expansion

Spending developer time to write code for the hypothetical someone running a psql version 11 linked to a libpq < 7.4, if it can even link, does not look like a very good investment... Anyway, here is required the update. The question is the server's version, not libpq. Ok. Modern psql does

Re: [HACKERS] Variable substitution in psql backtick expansion

Fabien COELHO writes: > Spending developer time to write code for the hypothetical someone running > a psql version 11 linked to a libpq < 7.4, if it can even link, does not > look like a very good investment... Anyway, here is required the update. The question is the

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Tom, I think you are taking unreasonable shortcuts here: + SetVariable(pset.vars, "SERVER_VERSION_NAME", PQparameterStatus(pset.db, "server_version")); The existing code in connection_warnings() does this: const char *server_version; /* Try to get full

Re: [HACKERS] Variable substitution in psql backtick expansion

Fabien COELHO writes: > 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. I think you are taking unreasonable shortcuts here: + SetVariable(pset.vars, "SERVER_VERSION_NAME",

Re: [HACKERS] Variable substitution in psql backtick expansion

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. [...]

Re: [HACKERS] Variable substitution in psql backtick expansion

Fabien COELHO writes: >> OK, but if human-friendly display is the use-case then it ought to >> duplicate what psql itself would print in, eg, the startup message about >> server version mismatch. The v4 patch does not, in particular it neglects >> PQparameterStatus(pset.db,

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Tom, ... 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 \echo this thing doesn't work on

Re: [HACKERS] Variable substitution in psql backtick expansion

On Fri, Aug 25, 2017 at 6:43 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Aug 25, 2017 at 6:09 PM, Tom Lane wrote: >>> ... I'm still not sure that there's any use case for the >>> string versions ("9.6.4" etc). > >> If

Re: [HACKERS] Variable substitution in psql backtick expansion

Robert Haas writes: > On Fri, Aug 25, 2017 at 6:09 PM, Tom Lane wrote: >> ... 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

Re: [HACKERS] Variable substitution in psql backtick expansion

On Fri, Aug 25, 2017 at 6:09 PM, Tom Lane 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

Re: [HACKERS] Variable substitution in psql backtick expansion

Robert Haas writes: > I am attempting to understand the status of this patch. It looks like > the patch that was the original subject of this thread was committed > as f833c847b8fa4782efab45c8371d3cee64292d9b on April 1st by Tom, who > was its author. Subsequently, a new

Re: [HACKERS] Variable substitution in psql backtick expansion

On Sun, May 21, 2017 at 11:37 AM, Fabien COELHO wrote: >> This patch has trivial implementation - and there are not any objection to >> used new variable names. >> >> 1. there was not any problem with patching, compiling >> 2. all regress tests passed >> 3. no problems with

Re: [HACKERS] Variable substitution in psql backtick expansion

Thanks for the pointer. I grepped for them without success. Here is a v4. I am sending a review of this patch. This patch has trivial implementation - and there are not any objection to used new variable names. 1. there was not any problem with patching, compiling 2. all regress tests

Re: [HACKERS] Variable substitution in psql backtick expansion

Hi 2017-04-02 21:57 GMT+02:00 Fabien COELHO : > > More to the point, we already have that. See c.h: >> >> #define CppAsString(identifier) #identifier >> #define CppAsString2(x) CppAsString(x) >> > > Thanks for the pointer. I grepped for them without success.

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-17 10:58 GMT+02:00 Fabien COELHO : > > I don't think so :?xxx is good idea, because for me :xxx is related to >> content, not to metadata >> > > Hmmm. Indeed it is not. I do not see it as an issue, but it is a good > point. > > Consider perl "defined $x" or "exists

Re: [HACKERS] Variable substitution in psql backtick expansion

I don't think so :?xxx is good idea, because for me :xxx is related to content, not to metadata Hmmm. Indeed it is not. I do not see it as an issue, but it is a good point. Consider perl "defined $x" or "exists $f{k}". $x/$f{k} should be contents, but it is not, the dereferencing is

Re: [HACKERS] Variable substitution in psql backtick expansion

> > > 4. because pgbench doesn't do early variable evaluation, implementation of >> "defined" function is easy - we can introduce some new syntax for >> implementation some bash patterns like "default value" or "own undefined >> message" >> > > Maybe. ISTM that a :* syntax should be thought for so

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Pavel, A more detailed answer to your many points. The pgbench expression language is perfect for us - there is not any new dependency - it is working on all supported platforms. Can be nice, if we can reuse pgbench expressions in psql - there are some task that should be solved first

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-17 1:00 GMT+02:00 Fabien COELHO : > > I checked the pgbench expr related code. >> > > 2. move pgbench expressions to separate module >> > > Probably already existing "fe_utils". > > 3. teach pgbench expressions booleans >> > > See

Re: [HACKERS] Variable substitution in psql backtick expansion

I checked the pgbench expr related code. 2. move pgbench expressions to separate module Probably already existing "fe_utils". 3. teach pgbench expressions booleans See https://commitfest.postgresql.org/14/985/ -- Fabien. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-12 1:42 GMT+02:00 Fabien COELHO : > > Hmmm. Although I do not buy this, it could work as a replacement for \set >>> which it seems cannot be upgraded because some people may rely on it to >>> just store whatever comes after it in a variable. >>> >> >> I have no strong

Re: [HACKERS] Variable substitution in psql backtick expansion

Fabien COELHO wrote: > Pavel also suggested some support for TEXT, although I would like to see a > use case. That could be another extension to the engine. SQLSTATE is text. Also when issuing "psql -v someoption=value -f script", it's reasonable to want to compare :someoptionvar to

Re: [HACKERS] Variable substitution in psql backtick expansion

Hmmm. Although I do not buy this, it could work as a replacement for \set which it seems cannot be upgraded because some people may rely on it to just store whatever comes after it in a variable. I have no strong opinion on how expressive expressions should be, but having a separate \expr (or

Re: [HACKERS] Variable substitution in psql backtick expansion

On Tue, Apr 11, 2017 at 2:56 AM, Fabien COELHO wrote: > > Hello Pavel, > > I think so some local expression evaluation could be - but it should not be >> placed in \if statement >> > > Why? > > \expr issupported :VERSION_NUM >= 1 >> > > Hmmm. Although I do not buy this,

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-11 9:07 GMT+02:00 Fabien COELHO : > > I think so implementation of simple expression evaluation should not be >> hard >> > > Indeed it is not hard, it is rather a matter of deciding what it should > do, and the syntax to do it. > > - really just - we can expect so any

Re: [HACKERS] Variable substitution in psql backtick expansion

I think so implementation of simple expression evaluation should not be hard Indeed it is not hard, it is rather a matter of deciding what it should do, and the syntax to do it. - really just - we can expect so any variable will be replaced by const in expression Num (<|>|=|<=|>=) Num

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-11 8:56 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > I think so some local expression evaluation could be - but it should not be >> placed in \if statement >> > > Why? > > \expr issupported :VERSION_NUM >= 1 >> > > Hmmm. Although I do not buy this, it could work

Re: [HACKERS] Variable substitution in psql backtick expansion

> > \else > \if :somevar > 1 and SERVER_NUM >= 10 > should be \if :somevar > 1 and :SERVER_NUM >= 10 > ... > \end > >

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Pavel, I think so some local expression evaluation could be - but it should not be placed in \if statement Why? \expr issupported :VERSION_NUM >= 1 Hmmm. Although I do not buy this, it could work as a replacement for \set which it seems cannot be upgraded because some people

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-11 8:17 GMT+02:00 Fabien COELHO : > > Hello Greg, > > SELECT some-boolean-expression AS okay \gset >>> \if :okay >>> >> >> Am I the only one who thinks that even if \if got the ability to >> evaluate arbitrary SQL queries I would probably still always write >>

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Greg, SELECT some-boolean-expression AS okay \gset \if :okay Am I the only one who thinks that even if \if got the ability to evaluate arbitrary SQL queries I would probably still always write things as above? I think putting arbitrary SQL expressions (let alone queries) would

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-10 13:07 GMT+02:00 Greg Stark : > On 2 April 2017 at 07:53, Fabien COELHO wrote: > > Note that this is already available indirectly, as show in the > > documentation. > > > > SELECT some-boolean-expression AS okay \gset > > \if :okay > > \echo

Re: [HACKERS] Variable substitution in psql backtick expansion

On 2 April 2017 at 07:53, Fabien COELHO wrote: > Note that this is already available indirectly, as show in the > documentation. > > SELECT some-boolean-expression AS okay \gset > \if :okay > \echo boolean expression was true > \else > \echo boolean expression

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-04 9:53 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > The expression evaluation is interesting question, but there is a >> workaround - we can use \gset already. >> > > Yes, that is a good point. It is a little bit inconvenient because it > requires a dummy variable

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Pavel, The expression evaluation is interesting question, but there is a workaround - we can use \gset already. Yes, that is a good point. It is a little bit inconvenient because it requires a dummy variable name each time for testing. SELECT whatever AS somename \gset \if

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-03 21:24 GMT+02:00 Fabien COELHO : > > Hello Tom, > > \if [select current_setting('server_version_num')::int < 11] >>> >> >> I really dislike this syntax proposal. >> > > It would get us into having to count nested brackets, and distinguish >> quoted from

Re: [HACKERS] Variable substitution in psql backtick expansion

On Mon, Apr 3, 2017 at 5:12 AM, Daniel Verite wrote: > Queries can be as complex as necessary, they just have to fit in one line. ​Line continuation in general is missed though I thought something already when in for 10.0 that improves upon this...​ > In no way at

Re: [HACKERS] Variable substitution in psql backtick expansion

\set d sqrt(1 + random(1000) * 17) \echo :d sqrt(1+random(1000)*17) I assume we want to keep that pre-existing behavior of \set in psql, Ok. So no interpreted expression ever in psql's \set for backward compatibility. that is, making a copy of that string and associating a name to it,

Re: [HACKERS] Variable substitution in psql backtick expansion

> > I assume we want to keep that pre-existing behavior of \set in > psql, that is, making a copy of that string and associating a > name to it, whereas I guess pgbench computes a value from it and > stores that value. > Maybe a \set-variant called \expr?

Re: [HACKERS] Variable substitution in psql backtick expansion

Fabien COELHO wrote: > Now it could be decided that \set in psql stays simplistic because it is > not needed as much as it is with pgbench. Fine with me. It's not just that. It's that currently, if we do in psql: \set d sqrt(1 + random(1000) * 17) then we get that: \echo :d

Re: [HACKERS] Variable substitution in psql backtick expansion

[...] but OTOH "\if sql 1 from table where expr" looks awkward. Given an implicit select, I would prefer "\if exists (select 1 from table where expr)" but now it's not shorter. Possibly, but it is just an SQL expression, which looks good in the middle of an sql script. An advantage of

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Tom, \if [select current_setting('server_version_num')::int < 11] I really dislike this syntax proposal. It would get us into having to count nested brackets, and distinguish quoted from unquoted brackets, and so on ... and for what? It's not really better than \if sql

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Daniel, - how would it work, both with \set ... and \if ...? The idea is that the need to have two command (a SELECT .. \gset followed by an \if) and a temporary variable in-between would be lifted by implementing a close equivalent in one command. It would behave essentially the

Re: [HACKERS] Variable substitution in psql backtick expansion

Tom Lane wrote: > I really dislike this syntax proposal. It would get us into having > to count nested brackets, and distinguish quoted from unquoted brackets, > and so on ... and for what? It's not really better than > > \if sql select 1 from pg_catalog.pg_extension where

Re: [HACKERS] Variable substitution in psql backtick expansion

"Daniel Verite" writes: > Let's imagine that psql would support a syntax like this: > \if [select current_setting('server_version_num')::int < 11] > or > \if [select 1 from pg_catalog.pg_extension where extname='pgcrypto'] I really dislike this syntax proposal.

Re: [HACKERS] Variable substitution in psql backtick expansion

Fabien COELHO wrote: > My 0.02 € about server-side expressions: ISTM that there is nothing > obvious/easy to do to include these: > > - how would it work, both with \set ... and \if ...? The idea is that the need to have two command (a SELECT .. \gset followed by an \if) and a

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Tom, about version numbers [...] Of course, there are probably other ways to do that, but my point is that you haven't made a case why we need to put this in now rather than later. Indeed, I have not. What about having the ability to test for minor versions? \if false -- pre

Re: [HACKERS] Variable substitution in psql backtick expansion

Fabien COELHO writes: >>> - how desirable/useful is it to have this in 10? >> Extensions and extension-ish packages will love the _NUM vars. > H. I'm afraid pg extension scripts (for CREATE EXTENSION) are not > executed through psql, but server side directly, so there

Re: [HACKERS] Variable substitution in psql backtick expansion

More to the point, we already have that. See c.h: #define CppAsString(identifier) #identifier #define CppAsString2(x) CppAsString(x) Thanks for the pointer. I grepped for them without success. Here is a v4. -- Fabiendiff --git a/doc/src/sgml/ref/psql-ref.sgml

Re: [HACKERS] Variable substitution in psql backtick expansion

src/tools/msvc/Solution.pm:s{PG_VERSION_STR "[^"]+"}{__STRINGIFY(x) #x\n#define __STRINGIFY2(z) __STRINGIFY(z)\n#define PG_VERSION_STR "PostgreSQL $self->{strver}$extraver, compiled by Visual C++ build " __STRINGIFY2(_MSC_VER) ", $bits-bit"}; Well, this is the same hack. Without digging too

Re: [HACKERS] Variable substitution in psql backtick expansion

Corey Huinker writes: > Looking at #define STRINGIFY(), I got curious where else STRINGIFY was used: > Without digging too deep, it seems like the redefinition wouldn't be > harmful, but it might make sense to not use the name STRINGIFY() if only to > avoid confusion with

Re: [HACKERS] Variable substitution in psql backtick expansion

On Sun, Apr 2, 2017 at 12:29 PM, Fabien COELHO wrote: > > Hello Corey, > > I'm anxious to help with these patches, but they seem a bit of a moving >> target. Happy to jump in and review as soon as we've settled on what >> should >> be done. >> > > The "v3" I sent basically

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Corey, I'm anxious to help with these patches, but they seem a bit of a moving target. Happy to jump in and review as soon as we've settled on what should be done. The "v3" I sent basically adds both client & server version numbers in client-side variables, basically same code as

Re: [HACKERS] Variable substitution in psql backtick expansion

On Sun, Apr 2, 2017 at 11:16 AM, Pavel Stehule wrote: > > > 2017-04-02 13:13 GMT+02:00 Fabien COELHO : > >> >> Hello Pavel, >> >> \echo :VERSION PostgreSQL 10devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4)

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-02 13:13 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > \echo :VERSION >>> PostgreSQL 10devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu >>> 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609, 64-bit >>> >>> Probably some :VERSION_NUM would make some sense. See attached

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Daniel, SELECT some-boolean-expression AS okay \gset \if :okay Yes, the question was whether we leave it as that for v10, or if it's worth a last-minute improvement for usability, assuming it's doable, similarly to what $subject does to backtick expansion for external evaluation.

Re: [HACKERS] Variable substitution in psql backtick expansion

Fabien COELHO wrote: > Note that this is already available indirectly, as show in the > documentation. > > SELECT some-boolean-expression AS okay \gset > \if :okay > \echo boolean expression was true > \else > \echo boolean expression was false > \endif Yes, the

Re: [HACKERS] Variable substitution in psql backtick expansion

Can be SERVER_VERSION_NUM taken from connection info? Here is a version with that, quite easy as well as the information was already there for other checks. I have not updated "help.c" because the initial VERSION was not presented there in the first place. Here is a v3 to fix the

Re: [HACKERS] Variable substitution in psql backtick expansion

Can be SERVER_VERSION_NUM taken from connection info? Here is a version with that, quite easy as well as the information was already there for other checks. I have not updated "help.c" because the initial VERSION was not presented there in the first place. -- Fabien.diff --git

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Pavel, \echo :VERSION PostgreSQL 10devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609, 64-bit Probably some :VERSION_NUM would make some sense. See attached PoC patch. Would it make sense? Maybe better name for you CLIENT_VERSION_NUM If

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-02 9:45 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > For this case can be nice to have function that returns server version as >> number some like version_num() .. 1 >> > > The server side information can be queried: > > SELECT

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-02 9:45 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > For this case can be nice to have function that returns server version as >> number some like version_num() .. 1 >> > > The server side information can be queried: > > SELECT

Re: [HACKERS] Variable substitution in psql backtick expansion

For this case can be nice to have function that returns server version as number some like version_num() .. 1 Another possible trick to get out of a script which does not support \if, relying on the fact that the unexpected command is simply ignored: -- exit version below 10 \if

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Pavel, For this case can be nice to have function that returns server version as number some like version_num() .. 1 The server side information can be queried: SELECT current_setting(‘server_version_num’) AS server_version_num \gset -- 90602 However client side is not so

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-02 8:53 GMT+02:00 Fabien COELHO : > > Bonjour Daniel, > > I think that users would rather have the option to just put >> an SQL expression behind \if. >> > > Note that this is already available indirectly, as show in the > documentation. > > SELECT

Re: [HACKERS] Variable substitution in psql backtick expansion

Bonjour Daniel, I think that users would rather have the option to just put an SQL expression behind \if. Note that this is already available indirectly, as show in the documentation. SELECT some-boolean-expression AS okay \gset \if :okay \echo boolean expression was true \else

Re: [HACKERS] Variable substitution in psql backtick expansion

Corey Huinker writes: > On Thu, Mar 30, 2017 at 1:33 PM, Tom Lane wrote: >> single-quoted according to Unix shell conventions. (So the >> processing would be a bit different from what it is for the >> same notation in SQL contexts.) > +1 Here's a

Re: [HACKERS] Variable substitution in psql backtick expansion

"Daniel Verite" writes: > ISTM that expr is too painful to use to be seen as the > idiomatic way of achieving comparison in psql. I'm not proposing it as the best permanent solution, just saying that having this in v10 is a lot better than having nothing in v10. And we

Re: [HACKERS] Variable substitution in psql backtick expansion

Corey Huinker writes: > On Thu, Mar 30, 2017 at 1:33 PM, Tom Lane wrote: >> single-quoted according to Unix shell conventions. (So the >> processing would be a bit different from what it is for the >> same notation in SQL contexts.) > Any reason we

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-03-31 15:00 GMT+02:00 Daniel Verite : > Tom Lane wrote: > > > Thoughts? > > ISTM that expr is too painful to use to be seen as the > idiomatic way of achieving comparison in psql. > > Among its disadvantages, it won't work on windows, and its > interface is

Re: [HACKERS] Variable substitution in psql backtick expansion

Tom Lane wrote: > Thoughts? ISTM that expr is too painful to use to be seen as the idiomatic way of achieving comparison in psql. Among its disadvantages, it won't work on windows, and its interface is hard to work with due to the necessary quoting of half its operators, and the

Re: [HACKERS] Variable substitution in psql backtick expansion

On Thu, Mar 30, 2017 at 1:33 PM, Tom Lane wrote: > single-quoted according to Unix shell conventions. (So the > processing would be a bit different from what it is for the > same notation in SQL contexts.) > +1 Having been bit by format '%L' prepending an 'E' to any string

Re: [HACKERS] Variable substitution in psql backtick expansion

On Fri, Mar 31, 2017 at 2:33 AM, Tom Lane wrote: > Awhile back in the discussion about the \if feature for psql, > I'd pointed out that you shouldn't really need very much in > the way of boolean-expression evaluation smarts, because you > ought to be able to use a backtick

[HACKERS] Variable substitution in psql backtick expansion

Awhile back in the discussion about the \if feature for psql, I'd pointed out that you shouldn't really need very much in the way of boolean-expression evaluation smarts, because you ought to be able to use a backtick shell escape: \if `expr :foo \> :bar` \echo :foo is