Re: [HACKERS] Variable substitution in psql backtick expansion - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] Variable substitution in psql backtick expansion
Date
Msg-id CAFj8pRCju2sT=mvZx0C0+R3Sm_zP81YMsdzqHgWQqvaAcdTCiA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Variable substitution in psql backtick expansion  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers


2017-04-17 10:58 GMT+02:00 Fabien COELHO <coelho@cri.ensmp.fr>:

I don't think so :?xxx is good idea, because for me :xxx is related to content, not to metadata

Hmmm. Indeed it is not. I do not see it as an issue, but it is a good point.

Consider perl "defined $x" or "exists $f{k}". $x/$f{k} should be contents, but it is not, the dereferencing is suspended by "defined/exists" Yuk, but simple and effective.

Also with CPP: "#define x 1, #ifdef x", somehow "x" should be the value, not the name, but yet again it is not dereferenced.

Now consider python: "if 'varname' in locals():" at least it is consistent, but I cannot say it looks better in the end:-)

So playing around with a value vs metadata is a frequent trick to keep the syntax simple, even if the logic is not all there as you point out.

and Robert's tip of using bash syntax is more logical for me (to have syntax for default and custom message).

There is no way to simply test for definition in bash, which is exactly what is needed...

A second issue with sh-like proposal is that it needs a boundary thing, i.e. bash uses braces ${name<operator>value}. If it was the beginning of psql I would suggest to consider ${name} stuff, but now I'm not sure that such a thing can be introduced like ":{xxx}" ? Maybe that can be done.

However it does not change the issue that sh does not allow to test whether a variable is defined, which is the thought for feature. Providing a default value or erroring out is not the same thing.

Another question to address: how do you handle ' and " escaping? Pg :'name' and :"name" solutions are somewhat horrible, but they are there which show that it was needed. I'm not sure how to translate that with braces in pg. Maybe :{'name'} and :{"name"}? Hmmm...
Or ":{name}", but then what happens if I write ':{n} x :{m}', should the lexer interpolate and escape them inside the strings? That is the sh solution, but I'm not sure it should be done now in psql.

I have same thinks. We can disallow nesting - it can be acceptable limit. The :{xxx:operator} can be used for more things - default, check, user input, ...

necessary escaping can be done in next line

 


I understand well so it is subjective - and more, don't think so this point is significant.

Well, depending on the syntax things can be done or not, eg test the variable definition server-side, not only client side. Hence the discussion:-)

It depends if variables are declared or defined by value. In psql there are defined by value. So some tests if var is defined or not is necessary.
 


We should to have this functionality.

Yes.

--
Fabien.

pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] pgbench - allow to store select results intovariables
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Failed recovery with new faster 2PC code