Re: [HACKERS] Undefined psql variables

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: [HACKERS] Undefined psql variables
Дата
Msg-id alpine.DEB.2.20.1704140716210.13649@lancre
обсуждение исходный текст
Ответ на Re: [HACKERS] Undefined psql variables  (Robert Haas <robertmhaas@gmail.com>)
Список 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.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: [HACKERS] Interval for launching the table sync worker
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Small patch for pg_basebackup argument parsing