On Sun, Mar 20, 2016 at 1:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Mar 18, 2016 at 10:02 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> This is mostly a flex/bison hack, isn't it? If you like I'll take it. > >> I would be delighted if you would. > > I've committed changes equivalent to Horiguchi-san's 0001 and 0002 > patches, though rather different in detail. I concur with the upthread > opinion that 0003 doesn't seem really necessary. > > This solves the problem of allowing SQL commands in scripts to span > lines, ...
Excellent. > but it doesn't do anything about backslash commands, which was > the original point according to the thread title ;-). Wait, was it really? I'd been thinking it was mostly to continue queries, not metacommands, but maybe I missed the boat. > I can think of > two somewhat-independent changes we might want to make at this point, > since we're breaking exact script compatibility for 9.6 anyway: > > * 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. > * 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> -- 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
