Re: PSQL commands: \quit_if, \quit_unless - Mailing list pgsql-hackers

Hello Corey,

> I agree that the boolean tests available should be *very* simple, and all
> of the weight of complex calculation should be put in SQL, like we do with
> \gset

Yes.

> I propose those be:
>
> \if STRING :  true if STRING evaluates to true via ParseVariableBool, empty
> means false

Yep.

> \ifnot STRING: true if STRING evaluates to false via ParseVariableBool,
> empty means false

I'd like other opinions about having unique \if and an not operator, vs 
multiplying \if* and possibly \elif* keywords.

> \ifdef psql_var: true if psql_var is defined
> \ifndef psql_var: true if psql_var is not defined, helpful for when --set
> var=val was omitted and should be defaulted

Hmmm. Would you have an example use case that could not be done simply 
with the previous ifs? cpp did that end ended up with a single if in the 
end.

> A full compliment of \elseif \elseifnot \elseifdef \elseifndef, each
> matching the corresponding \if* above. I'm ok with these being optional in
> the first revision.

> \else   - technically we could leave this out as well
> \endif

For consistency, the possible sources of inspiration for a syntax with an 
explicit end marker are:
 - PL/pgSQL: if / then / elsif / else / endif - cpp: if / elif / else / endif - sh: if / then / elif / else / fi

Now "then" is useless in a line oriented syntax, for which the closest 
example above is cpp, which does not have it. I think that we should stick 
to one of these.

I like the shell syntax (without then), but given the line orientation 
maybe it would make sense to use the cpp version, close to what you are 
proposing.

I cannot remember a language with elseif* variants, and I find them quite 
ugly, so from an aethetical point of view I would prefer to avoid that... 
On the other hand having an "else if" capability makes sense (eg do 
something slightly different for various versions of pg), so that would 
suggest to stick to a simpler "if" without variants, if possible.

> Then seems like we need an if-state-stack to handle nesting. [...]

Yes, a stack or recursion is needed for implementing nesting.

> States: None, If-Then, If-Skip, Else-Then, Else-Skip.

With an "else if" construct you probably need some more states: You have 
to know whether you already executed a block in which case a subsequent 
condition is ignored, so there is a state "skip all to end" needed.

> Does that seem work-able?

Sure. I think the priority is to try to agree about a syntax, the 
implementation is a detail.

-- 
Fabien.