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

From Corey Huinker
Subject Re: [HACKERS] Undefined psql variables
Date
Msg-id CADkLM=eJi_4E9DuhUPq6T_-nh+eX0OY0Sa631Uu4o6cq6bq8cQ@mail.gmail.com
Whole thread Raw
In response to [HACKERS] Undefined psql variables  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: [HACKERS] Undefined psql variables  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Re: [HACKERS] Undefined psql variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On Sun, Apr 2, 2017 at 4:57 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:

I'm inclined to suggest that we should require all extensions beyond the
boolean-literal case to be set up as a keyword followed by appropriate
argument(s); that seems like it's enough to prevent syntax conflicts from
future additions.  So you could imagine

        \if defined varname
        \if sql boolean expression to send to server
        \if compare value operator value

I'm still thinking:-)

Independently of the my aethetical complaint against having a pretty unusual keyword prefix syntax, how would you envision a \set assignment variant? Would \if have a different expression syntax somehow?

Any further thoughts?


 

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Collect and use multi-columndependency stats
Next
From: David Rowley
Date:
Subject: Re: [HACKERS] Performance improvement for joins where outer side is unique