On Wed, May 13, 2015 at 3:54 PM, Fabien COELHO <coe...@cri.ensmp.fr> wrote: > Ok. I've marked this one as REJECTED. > > Otherwise, I was considering this kind of things: > > n := expr > n, m, p, q := SELECT ... > > 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.
It's been my assumption that we wanted to keep the existing pgbench syntax mostly intact, and extend it. We could, of course, invent a completely new syntax, but it might be hard to get everybody to agree on what the new thing should look like. 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. Another option, breaking backward compatibility, would be to decide that backslash commands have to be terminated by a semicolon token. Then we wouldn't need a continuation character, because we'd just continue across lines until we hit the terminator. Of course, that doesn't solve the problem for people who want to include 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. Then it could identify properly-terminated SQL queries automatically. That, too, would be a backward compatibility break, since the terminating semicolon would become required there as well. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers