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

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:

Reply via email to