Hello Robert,
Also, having ";" as a end of commands could also help by allowing multiline
commands, but that would break compatibility. Maybe allowing continuations
(\\\n) would be an acceptable compromise.
I loathe violently the convention of using a backslash at the end of a
line, because it's too easy to write backslash-space-newline or
backslash-tab-newline when you meant to write backslash-newline. But
maybe we should do it anyway. We certainly need some solution to that
problem, because the status quo is monumentally annoying, and that might
be the least bad solution available.
I survive with that in bash/make/python...
Another option, breaking backward compatibility, would be to decide
that backslash commands have to be terminated by a semicolon token.
I do not like it much, as it is inconsistent/incompatible with "psql".
[...] multi-line SQL queries. If we wanted to make that work, the best
option might be to duplicate the backend lexer into pgbench just as we
already do with psql. [...]
I somewhat lean toward this second option, because I think it will be
a lot more convenient in the long run. We'll probably get some
complains about breaking people's pgbench scripts, but I'd personally
be prepared to accept that as the price of progress.
For an actual lexer: currently there is no real lexer for SQL commands in
pgbench, the line is just taken as is, so that would mean adding another
one, although probably a simplified one would do.
To conclude, I'm rather for continuations, despite their ugliness, because
(1) it is much easier (just a very small change in read_line_from_file)
and (2) it is backward compatible, so no complaints handle.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
