On Mon, Dec 5, 2016 at 12:32 PM, Robert Haas <robertmh...@gmail.com> wrote: >> - possible incremental implemention steps on this path: >> >> (1) minimal condition and expression, compatible with >> a possible future full-blown expression syntax >> >> \if :variable >> \if not :variable -- maybe \if ! :variable >> ... >> \endif >> >> (2) add "\else" >> >> (3) add "\elif ..." (or maybe "\elsif ..."?) >> >> (4) add greater but limited expressions, compatible with a full blown >> expression syntax (eg \if :var/const <comparison-operator> :var/const) >> >> (5) add full-blown <expression> support for \if, which suggest that >> it would also be available for \set >> >> >> Does this looks okay, or does it need to be amended? >> >> A few comments: >> >> Given the experience with pgbench and the psql context, I do not think that >> it would really need to go beyond step 2 above, but I agree that I may be >> wrong and it is best to be prepared for that from the start. Given the >> complexity and effort involved with (5), it seems wise to wait for a clearer >> motivation with actual use-cases before going that far. > > Well, my vote would be to go all the way to #5 in one commit. > Stopping short of that doesn't seem to me to save enough work to make > much sense. I don't think we're talking about anything all that > complex, and it will make future improvements a lot simpler.
After having thought about this a little bit further and reread this a bit more carefully, I would like to revise my position. Really, what I don't want to end up with is a hand-coded expression syntax that is very limited which then has to be replaced with a full-blown lexer and parser. That is, I do not want to ever be at step "4" of this proposal. So I think it would be reasonable for somebody to implement \if, \elseif, \endif first, with the argument having to be, precisely, a single variable and nothing else (not even a negator). Then a future patch could allow an expression there instead of a variable. I don't think that would be any harder to review than going all the way to #5 in one shot, and actually it might be simpler. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
