Re: [HACKERS] Undefined psql variables

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] Undefined psql variables
Дата
Msg-id CAFj8pRAHJJYzt7wm6DkqXPwkBjGCHROx=tA=Ou_zykM7YCnp4g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Undefined psql variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: [HACKERS] Undefined psql variables
Список pgsql-hackers


2017-04-07 21:04 GMT+02:00 Fabien COELHO <coelho@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.

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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] Remaining 2017-03 CF entries
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem