Re: Undefined psql variables

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Undefined psql variables
Date: 2017-04-13 22:58:50
Message-ID: alpine.DEB.2.20.1704140716210.13649@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Robert,

>> Calling the server is already available:
>>
>> SELECT <whatever> 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 that way can also be done this way, but
> people will want it just to make the code look nicer.

That is what I thought, but I have not seen any sane/nice solution, and I
wish to avoid the opposite.

I now think that whether an expression is server side or client side
should be cristal clear, thus the rule "write a SELECT for server-side"
and "write a backslash command" for client-side is pretty attractive.

I do not think it is so bad: this is probably a rare occurence (psql spent
22 years without "\if") ; for server side expressions, it means that an
intermediate meaningful variable name must be thought for, which is not
necessarily a bad thing ; any significant SQL query would not fit cleanly
on one line, especially if made longer by a special prefix.

Finally, it does not bring any new semantics.

> I don't think we should restrict \if to be ONLY an SQL callout, but if
> people want that as an option, and I bet they do, then I think we should
> give it to them.

I changed my mind on this one. I think we should not for the reason stated
above.

Now it would be possible to have some compromise, and we could accept some
ugly prefix to mark server-side expressions after \if and no special
prefix would mean client-side, but the I would prefer if we avoid that.

>> I somewhat disagree: Does building postgres should depend on lua? I think
>> adding such a mandatory dependency would not be a good idea. If it is not
>> mandatory, then it would mean that psql could be compiled with or without
>> lua embedding, thus psql would not be dependable because features may or may
>> not be available when writing a "psql script".
>
> That's true, but you could say the same thing about SSL or NLS.

Hmmm. I'm not sure how NLS or SSL would show up inside a psql-script.

Another point I would like to make is that lua popularity is somewhere
between COBOL and Fortran on the Tiobe index.

> [...] I don't think it's likely that adding one or two additional simple
> constructs is going to be sufficient to keep people from wanting more.

I think that the next hurdle is high enough for not being jumped over in a
hurry: for getting a while, one need to re-execute the body over and over,
which requires holding the lines somewhere, meaning an significant
infrastructure which does not exists. So someone would have to need it
really badly to spend time on this one.

>> Generating a error message with ${foo:?} is nice, but what psql need is just
>> a way to test whether a variable is defined or not.
>
> I'm not saying we should slavishly follow bash, but don't confuse what
> you need with what other people need. bash (well, sh, really) grew
> that syntax for a reason, and it may be more than "there was this one
> guy back in the seventies who wanted it, and ...".

Sure. I think that the reason is to be able to write shell scripts without
bothering with undefined variables error handling. Lazy programmers:-)

--
Fabien.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-04-13 23:44:37 Re: Small patch for pg_basebackup argument parsing
Previous Message Petr Jelinek 2017-04-13 22:09:23 Re: Interval for launching the table sync worker