Re: [HACKERS] Undefined psql variables

2017-04-13 Thread Fabien COELHO
Hello Robert, Calling the server is already available: SELECT AS varname \gset Sure, but people are going to want to do it inline with the \if. Yes... and my changed opinion is that the answer to this approach should be "no", only client side after if. Anything that can be done

Re: [HACKERS] Undefined psql variables

2017-04-13 Thread Pavel Stehule
2017-04-13 19:46 GMT+02:00 Corey Huinker : > >> > I suggest to reuse pgbench expression engine, developed by Haas >> Robert:-) >> >> Not a bad idea (though I'm sure there are other reasonable options, too). >> >> > I don't want to stand in the way of any progress in

Re: [HACKERS] Undefined psql variables

2017-04-13 Thread Pavel Stehule
> > > I suggest to reuse pgbench expression engine, developed by Haas Robert:-) > > Not a bad idea (though I'm sure there are other reasonable options, too). > I checked the pgbench code - and I think it can work well - just add logical operators and compare operators. Don't need to create more

Re: [HACKERS] Undefined psql variables

2017-04-13 Thread Corey Huinker
> > > > I suggest to reuse pgbench expression engine, developed by Haas Robert:-) > > Not a bad idea (though I'm sure there are other reasonable options, too). > > I don't want to stand in the way of any progress in getting expressions into \if and some subspecies of \set. But, assuming we don't

Re: [HACKERS] Undefined psql variables

2017-04-13 Thread Robert Haas
On Thu, Apr 13, 2017 at 8:56 AM, Fabien COELHO wrote: > Calling the server is already available: > > SELECT AS varname \gset Sure, but people are going to want to do it inline with the \if. Anything that can be done that way can also be done this way, but people will want

Re: [HACKERS] Undefined psql variables

2017-04-13 Thread Fabien COELHO
Hello Robert, My 0.02€ about your interesting questions and points. On Sun, Apr 2, 2017 at 3:56 PM, Tom Lane wrote: So my view of this is that "send the expression to the server" ought to be just one option for \if, not the only way to do it. I heartily agree. There

Re: [HACKERS] Undefined psql variables

2017-04-12 Thread Pavel Stehule
2017-04-12 17:05 GMT+02:00 Robert Haas : > On Sun, Apr 2, 2017 at 3:56 PM, Tom Lane wrote: > > So my view of this is that "send the expression to the server" ought > > to be just one option for \if, not the only way to do it. > > I heartily agree.

Re: [HACKERS] Undefined psql variables

2017-04-12 Thread Robert Haas
On Sun, Apr 2, 2017 at 3:56 PM, Tom Lane wrote: > So my view of this is that "send the expression to the server" ought > to be just one option for \if, not the only way to do it. I heartily agree. There should be some kind of client-side expression language, and one thing it

Re: [HACKERS] Undefined psql variables

2017-04-08 Thread Pavel Stehule
2017-04-08 12:25 GMT+02:00 Fabien COELHO : > > Hello Pavel, > n > >> you proposal disallow client side expressions. >> > > I do agree that some client side expressions are necessary. I do not want > to disallow them. > > I agree so is not possible to mix server side and

Re: [HACKERS] Undefined psql variables

2017-04-08 Thread Fabien COELHO
Hello Pavel, n you proposal disallow client side expressions. I do agree that some client side expressions are necessary. I do not want to disallow them. I agree so is not possible to mix server side and client side expressions. My point is that a minimal of cross-support is possible.

Re: [HACKERS] Undefined psql variables

2017-04-07 Thread Pavel Stehule
2017-04-07 21:04 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > I wish I could have an explanation about why the :?varname (or some other >>> variant) syntax I suggested has a "namespace" issue. >>> >>> The advantage that I see is that although it is obviously ugly, it is >>>

Re: [HACKERS] Undefined psql variables

2017-04-07 Thread Fabien COELHO
Hello Pavel, I wish I could have an explanation about why the :?varname (or some other variant) syntax I suggested has a "namespace" issue. The advantage that I see is that although it is obviously ugly, it is ugly in the continuity of the various :["'?]varname syntaxes already offered and it

Re: [HACKERS] Undefined psql variables

2017-04-07 Thread Pavel Stehule
2017-04-07 9:52 GMT+02:00 Fabien COELHO : > > Hello Corey, > > \if defined varname \if sql boolean expression to send to server \if compare value operator value >>> >>> I'm still thinking:-) >>> >>> Independently of the my aethetical

Re: [HACKERS] Undefined psql variables

2017-04-07 Thread Fabien COELHO
Hello Corey, \if defined varname \if sql boolean expression to send to server \if compare value operator value I'm still thinking:-) Independently of the my aethetical complaint against having a pretty unusual keyword prefix syntax, how would you envision a \set

Re: [HACKERS] Undefined psql variables

2017-04-06 Thread Kyotaro HORIGUCHI
At Thu, 6 Apr 2017 19:21:21 -0400, Corey Huinker wrote in

Re: [HACKERS] Undefined psql variables

2017-04-06 Thread Corey Huinker
On Sun, Apr 2, 2017 at 4:57 PM, Fabien COELHO wrote: > > I'm inclined to suggest that we should require all extensions beyond the >> boolean-literal case to be set up as a keyword followed by appropriate >> argument(s); that seems like it's enough to prevent syntax conflicts

Re: [HACKERS] Undefined psql variables

2017-04-02 Thread Fabien COELHO
I'm inclined to suggest that we should require all extensions beyond the boolean-literal case to be set up as a keyword followed by appropriate argument(s); that seems like it's enough to prevent syntax conflicts from future additions. So you could imagine \if defined varname

Re: [HACKERS] Undefined psql variables

2017-04-02 Thread Fabien COELHO
Hello, For checking variable definition, I would suggest to extend the variable access syntax so that there is no exception to the one thing rule between client side and server side evaluation: \if :?variable Don't like that one bit; Possibly:-) This is kind of a shell-like hack

Re: [HACKERS] Undefined psql variables

2017-04-02 Thread Fabien COELHO
Hello Tom, I'm just arguing that for pgbench the evaluator needs to be on the client side, which implies a lexer, parser and executor. For psql, it does not really matter where the evaluator is, thus relying on the server should be fine and simpler and also powerful, provided the necessary

Re: [HACKERS] Undefined psql variables

2017-04-02 Thread Tom Lane
Fabien COELHO writes: > For checking variable definition, I would suggest to extend the variable > access syntax so that there is no exception to the one thing rule between > client side and server side evaluation: >\if :?variable Don't like that one bit; you're going

Re: [HACKERS] Undefined psql variables

2017-04-02 Thread Tom Lane
Fabien COELHO writes: > I'm just arguing that for pgbench the evaluator needs to be on the client > side, which implies a lexer, parser and executor. For psql, it does not > really matter where the evaluator is, thus relying on the server should be > fine and simpler and

Re: [HACKERS] Undefined psql variables

2017-04-02 Thread Fabien COELHO
Hello Pavel, I have convinced myself that, unlike pgbench, psql does not really need an advanced client-side-implemented language, so the smaller the better. What I mean by this is that from psql point of view it is ok that the actual expression evaluation is performed server-side. From a user

Re: [HACKERS] Undefined psql variables

2017-04-02 Thread Pavel Stehule
2017-04-02 18:56 GMT+02:00 Fabien COELHO : > > Hello Tom, > > I'm inclined to suggest that we should require all extensions beyond the >> boolean-literal case to be set up as a keyword followed by appropriate >> argument(s); that seems like it's enough to prevent syntax

Re: [HACKERS] Undefined psql variables

2017-04-02 Thread Pavel Stehule
2017-04-02 18:29 GMT+02:00 Tom Lane : > Corey Huinker writes: > > On Mon, Jan 23, 2017 at 12:53 PM, Tom Lane wrote: > >> This seems pretty bizarre. What's the use case? Why would it not > >> be better to build the behavior out

Re: [HACKERS] Undefined psql variables

2017-04-02 Thread Fabien COELHO
Hello Tom, I'm inclined to suggest that we should require all extensions beyond the boolean-literal case to be set up as a keyword followed by appropriate argument(s); that seems like it's enough to prevent syntax conflicts from future additions. So you could imagine \if defined

Re: [HACKERS] Undefined psql variables

2017-04-02 Thread Tom Lane
Corey Huinker writes: > On Mon, Jan 23, 2017 at 12:53 PM, Tom Lane wrote: >> This seems pretty bizarre. What's the use case? Why would it not >> be better to build the behavior out of other spare parts, along the >> lines of COALESCE or perhaps >>

Re: [HACKERS] Undefined psql variables

2017-04-02 Thread Corey Huinker
On Mon, Jan 23, 2017 at 12:53 PM, Tom Lane wrote: > Corey Huinker writes: > > I was giving some thought to how psql handles undefined variables. > > I would like an option where either psql can provide an alternate value > > when an undefined

Re: [HACKERS] Undefined psql variables

2017-01-23 Thread Fabien COELHO
Back in the day, PG allowed ":" as a generic operator name, making this even worse; but I think the only remaining SQL syntax that could include a colon is array slicing. Ok, so the behavior of replacing ":unknown" by same cannot be changed. Some fun: \set 1 1 SELECT

Re: [HACKERS] Undefined psql variables

2017-01-23 Thread Tom Lane
"David G. Johnston" writes: > On Mon, Jan 23, 2017 at 11:16 AM, Fabien COELHO wrote: >> Currently the value of a non existing psql-variable is... its own >> reference:-( >> >> psql> \echo :x >> :x >> >> I'm not sure of the rational, apart from

Re: [HACKERS] Undefined psql variables

2017-01-23 Thread David G. Johnston
On Mon, Jan 23, 2017 at 11:16 AM, Fabien COELHO wrote: > > [...] Obviously the \if stuff is things we don't have yet either, but it >>> seems less likely to have surprising side-effects. >>> >> > I agree, a more generic solution seems better than an ad-hoc one. > > Currently

Re: [HACKERS] Undefined psql variables

2017-01-23 Thread Fabien COELHO
[...] Obviously the \if stuff is things we don't have yet either, but it seems less likely to have surprising side-effects. I agree, a more generic solution seems better than an ad-hoc one. Currently the value of a non existing psql-variable is... its own reference:-( psql> \echo :x >

Re: [HACKERS] Undefined psql variables

2017-01-23 Thread Pavel Stehule
2017-01-23 18:53 GMT+01:00 Tom Lane : > Corey Huinker writes: > > I was giving some thought to how psql handles undefined variables. > > I would like an option where either psql can provide an alternate value > > when an undefined variable is

Re: [HACKERS] Undefined psql variables

2017-01-23 Thread Corey Huinker
On Mon, Jan 23, 2017 at 12:53 PM, Tom Lane wrote: > Corey Huinker writes: > > I was giving some thought to how psql handles undefined variables. > > I would like an option where either psql can provide an alternate value > > when an undefined

Re: [HACKERS] Undefined psql variables

2017-01-23 Thread Tom Lane
Corey Huinker writes: > I was giving some thought to how psql handles undefined variables. > I would like an option where either psql can provide an alternate value > when an undefined variable is referenced, or a way to detect that a > specific variable is undefined and

Re: [HACKERS] Undefined psql variables

2017-01-23 Thread Corey Huinker
On Mon, Jan 23, 2017 at 12:49 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > I have followed the "\if" thread that closely but IIRC that was part of > the discussion there. > > Yes, I'm trying to split some of those side-thoughts into their own threads.

Re: [HACKERS] Undefined psql variables

2017-01-23 Thread David G. Johnston
On Mon, Jan 23, 2017 at 10:34 AM, Corey Huinker wrote: > I was giving some thought to how psql handles undefined variables. > > I would like an option where either psql can provide an alternate value > when an undefined variable is referenced, or a way to detect that a >