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


I propose those be:

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


\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

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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to