Re: PSQL commands: \quit_if, \quit_unless

On Mon, Dec 5, 2016 at 12:32 PM, Robert Haas <robertmhaas(at)gmail(dot)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