2017-04-07 21:04 GMT+02:00 Fabien COELHO <coe...@cri.ensmp.fr>: > > 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 allows to get rid of "defined varname" which does not look like SQL. A >>> second advantage is that with the "defined" proposal >>> >> >> I don't think so this argument is valid - \if doesn't look like SQL too. >> > > Sure. I'm talking about the expressions after the "\if" which should be as > close as SQL, I think. At least that is what Tom required about the > expression syntax in pgbench, and I tend to agree that psql should avoid to > mix in another language if possible. > > \if defined var1 and defined var2 or defined var3 and sqlrt() >= .. >>> >>> Would probably never work work, as it cannot be embedded in another >>> expression, while it would work with >>> >>> \if :?var1 and :?var2 or :?var3 and ... >>> >>> I don't see any reason why first should not work and second should to >> work >> > > Because of the mix of client-side and server-side stuff which needs to be > interpreted. Let us consider: > > \if EXISTS (SELECT * FROM tbl WHERE id=3) AND defined foo > > The "exists" is obviously executed server-side, but "defined foo" needs to > be interpreted client-side, and it means that some parser client side would > have been able to catch it in the middle of everything else. This example > also illustrate my "does not look like SQL" point, as the first part is > clearly SQL and the part after AND is not. > > With the second approach, ... "AND :?foo", the ":?foo" reference would be > substituted directly by psql lexer and replaced on the fly by the answer, > resulting in "AND TRUE" or "AND FALSE" depending, then the whole result > (from EXISTS to TRUE/FALSE) could be interpreted server side to get an > answer. > > Basically, catching :?varname seems easier/safer than catching "defined > varname". I think that Tom's intent is that the defined expressions could > not be mixed with SQL server side stuff, but I do not see why not, it is > easy to imagine some use case where it would make sense. > > I have a different opinion - the condition expression should not be SQL >> necessary. This language is oriented on client side operations. What is >> benefit from server side expression? >> > > Because I think it is legitimate to be able to write things like: > > \if NOT pg_extension_is_loaded('units') > \echo 'this application requires the great units extension' > \q > \endif > > \if (SELECT version FROM app_version) >= 2.0 > \echo 'application already installed at 2.0' > \q > \endif > > you proposal disallow client side expressions. I agree so is not possible to mix server side and client side expressions. But I am sceptic so benefit of server side expression is higher than a lost of client side expressions. If we disallow server side expressions, then your examples are only two lines longer, but the implementation can be more simpler.
SELECT version FROM app_version \gset \if :version >= 2.0 ... Still I don't think so server side expression in \if is good idea. Regards Pavel > -- > Fabien. >