Re: PSQL commands: \quit_if, \quit_unless

>
>
> 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.