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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
