psql:not_defined.sql:3: ERROR: syntax error at or near ":"
LINE 1: select :'foo';
^
Now, if we instead added a way for psql to test whether or not a psql var was defined and set that boolean as ANOTHER variable, then we could avoid \ifdef and \ifndef.
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 think we should use pl/pgsql as our inspiration, though there's no need for the "then" because psql commands end the line....which makes it identical to the C++ version.
But if we can get this thing done, I really don't care which we use.
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.
We need to keep things easy to parse. Earlier someone said no psql command should ever have more than 2 parameters, and generally only one. Increasing the number of commands allows us to avoid multi-parameter commands. So it's a trade-off, we have more, simpler commands, or fewer, more complicated ones.
\if [not] [defined] [<string>]
\elsif [not] [defined] [<string>]
is problematic if string is ever "not" or "defined". If someone can show me a way around that, I'm game.
Then seems like we need an if-state-stack to handle nesting. [...]
Yes, a stack or recursion is needed for implementing nesting.
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.
Right, we'd have to check every level of the stack for a skip-state, not a big deal.