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
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
>
> > 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
>
>
> > 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
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
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
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.
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
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
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.
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
>>>
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
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
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
At Thu, 6 Apr 2017 19:21:21 -0400, Corey Huinker
wrote in
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
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
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
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
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
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
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
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
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
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
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
>>
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
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
"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
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
[...] 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
>
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
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
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
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.
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
>
36 matches
Mail list logo