On Mon, Mar 21, 2016 at 3:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Wait, was it really? I'd been thinking it was mostly to continue >> queries, not metacommands, but maybe I missed the boat. > > Nah, you're right, it was about continuing queries. Still, we've had > complaints about the other thing too, and I think if we're going to > change anything here, we should change it all in the same release.
Fair enough. >>> * Allow multiple backslash commands on one line, eg >>> \set foo 5 \set bar 6 >>> The main reason for that is that psql allows it, and one of the things >>> we're supposedly trying to do here is reduce the behavioral distance >>> between psql and pgbench parsing rules. > >> This seems to me to be going in the wrong direction. > > Um, why exactly? That psql behavior is of really ancient standing, and > we have not had complaints about it. I think that's mostly because the psql metacommands are ridiculously impoverished. I'm guessing that pgbench's expression language is eventually going to support strings as a data type, for example, and those strings might want to contain backlashes. There's basically no value in cramming multiple metacommands onto a single line, but there is the risk of creating unnecessary lexing or parsing difficulties in the future. >>> * Allow backslash commands to span lines, probably by adopting the >>> rule that backslash immediately followed by newline is to be ignored >>> within a backslash command. This would not be compatible with psql, >>> though, at least not unless we wanted to change psql too. > >> This might have some point to it, though, if you want to say \set i >> <incredibly long expression not easily contained on a single line> > > Shall I make a patch that allows backslash-newline to be handled this way > in both psql and pgbench backslash commands? At least in psql, there > would be no backwards compatibility problem, since right now the case > just fails: > > regression=# \set x y \ > Invalid command \. Try \? for help. I certainly don't object to such a patch, although if it's between you writing that patch and you getting Tomas Vondra's multivariate statistics stuff committed, I'll take the latter. :-) -- 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
