Re: [HACKERS] Undefined psql variables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] Undefined psql variables
Date
Msg-id CAFj8pRDmbcxy1mrVMFQ9UabB2QSLZmOut7v_KMRnVWssCHJ=UQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Undefined psql variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers


2017-04-08 12:25 GMT+02:00 Fabien COELHO <coelho@cri.ensmp.fr>:

Hello Pavel,
n
you proposal disallow client side expressions.

I do agree that some client side expressions are necessary. I do not want to disallow them.

I agree so is not possible to mix server side and client side expressions.

My point is that a minimal of cross-support is possible.

But I am sceptic so benefit of server side expression is higher than a lost of client side expressions.

There is a misunderstanding. I am not against client side expression. I do want to allow the same server & client side capabilities suggested by Tom, I'm just arguing about the syntax, to avoid a prefix oriented approach.

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.

Ok, so you do not like server-side expression capabities integrated to \if. I understood that you were in favor of Tom's proposal.

In this moment I see difficult implementation of \if expressions if we should to separate server side and client side expressions. The prefix oriented approach is used well in PLpgSQL

FOR IN SELECT, FOR IN ARRAY, FOR IN 1..x 

Tom's design should be more simply for implementation and can be simply extended. There is clean if expr is client side or server side. 

 

From a semantical point of view they are not necessary because the same effect can be obtained through \gset, at the price of an intermediate variable. So the server-side thing is just a syntax convenience. I think that independently of whether they are added, Tom's point is that it should be possible to add those features later on, hence the discussion about a design.

We are talking about primitive scripting language - that should be simple how it is possible. One command more, or performance there are not important - if the performance will not be terrible. The overhead of intermediate variable is +/- zero against remote expression. But back to main issue. We should to find syntax if some variable is defined and can be used or not.

Maybe the solution should not be directly joined with \if command.

what do you think about special \set command, that can be active only when variable is not defined.

some like

  \setifempty xxx default

Regards

Pavel 
 


--
Fabien.

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Fwd: Re: [HACKERS] Running make check-world in buildfarm (was Re:[COMMITTERS] pgsql: Use SASLprep to normalize passwords for SCRAMauthentication.)
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] [sqlsmith] Planner crash on foreign table join