Re: [HACKERS] Undefined psql variables - Mailing list pgsql-hackers
From | Fabien COELHO |
---|---|
Subject | Re: [HACKERS] Undefined psql variables |
Date | |
Msg-id | alpine.DEB.2.20.1704140716210.13649@lancre Whole thread Raw |
In response to | Re: [HACKERS] Undefined psql variables (Robert Haas <robertmhaas@gmail.com>) |
List | 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 by date: