On Thu, Feb 9, 2017 at 3:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: > > I (still) think this is a bad design. Even if you've got all the > > messages just right as things stand today, some new feature that comes > > along in the future can change things so that they're not right any > > more, and nobody's going to relish maintaining this. > > FWIW, I tend to agree that this is way overboard in terms of the amount of > complexity going into the messages. Also, I do not like what seems to > be happening here: > > >> $ psql test < test2.sql -v ON_ERROR_STOP=0 > >> unrecognized value "error" for "\if <expr>": boolean expected > >> new \if is invalid, ignoring commands until next \endif > > IMO, an erroneous backslash command should have no effect, period. > "It failed but we'll treat it as if it were valid" is a rathole > I don't want to descend into. It's particularly bad in interactive > mode, because the most natural thing to do is correct your spelling > and issue the command again --- but if psql already decided to do > something on the strength of the mistaken command, that doesn't work, > and you'll have to do something or other to unwind the unwanted > control state before you can get back to what you meant to do. > > regards, tom lane >
One way around this is to make the small change: commands with invalid expressions are ignored in interactive mode. Another way around it would be to ignore branching commands in interactive mode altogether and give a message like "branching commands not supported in interactive mode". That'd get rid of a lot of complexity right there. I for one wouldn't miss it. The only use I saw for it was debugging a script, and in that case the user can be their own branching via selective copy/paste. Do either of those sound appealing?