At Thu, 6 Apr 2017 19:21:21 -0400, Corey Huinker <corey.huin...@gmail.com>
wrote in <CADkLM=eji_4e9duhupq6t_-nh+ex0oy0sa631uu4o6cq6bq...@mail.gmail.com>
corey.huinker> On Sun, Apr 2, 2017 at 4:57 PM, Fabien COELHO
<coe...@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?
If I read Fabien's words correctly, I think \if is different from
\set in what they take and the parameters will be interpreted.
I suppose that we are assuming a very simple parser here. If
there's a possibility to use the first parameter of '\if' as the
kind/interpretation of the following parameters, expressions in
'\if <expr>' should be distinguishable from them only by reading
the first word.
This means that expression also requires to be prefixed by a kind
word (as the "compare" in Tom's suggestion) or prefixed or
enclosed with non-word characters. '\if (<expr>)' for
example. But I'm not sure how represent 'not defined' in this
way.
Or, as Pavel suggested upthread, we could add dedicate keyword
for each type of 'if's. Such as '\if <expr>', "\if(n/un)def
<varname>' and other '\if_blah_blah's.
Otherwise we could introduce pseudo-functions instead, but this
is unnecessarily complex for this case.
| \if defined(<varname>) && execute('select version()')) ~= / 10 devel/
# Ugh.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
