> > > 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.
I think this is what you're asking for... $ cat not_defined.sql select :'foo'; $ psql postgres --no-psqlrc -f not_defined.sql --set foo=bar ?column? ---------- bar (1 row) $ psql postgres --no-psqlrc -f not_defined.sql 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. > > 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. > Right, we'd have to check every level of the stack for a skip-state, not a big deal.