Re: pgbench - allow backslash continuations in \set expressions
Fabien COELHO <coelho@cri.ensmp.fr>
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Rafia Sabih <rafia.sabih@enterprisedb.com>,
Robert Haas <robertmhaas@gmail.com>,
PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2017-01-20T13:00:51Z
Lists: pgsql-hackers
Attachments
- pgbench-continuation-5.patch (text/x-diff) patch
- cont.sql (application/x-sql)
- (unnamed) (text/plain)
> You have rules for
>
> {nonspace}+ [...]
> {continuation}
>
> Remember that flex always takes the rule that produces the longest match
> starting at the current point. {space}+ and {newline} don't conflict with
> continuations, but {nonspace}+ does:
Indeed, I totally overlooked "{nonspace}+".
> [...] I think this is surprising and inconsistent.
Sure.
> Probably the easiest fix is to add a rule that explicitly matches this
> situation:
>
> {nonspace}+{continuation} { ... throw back 2 chars and return the rest ... }
Well, as the continuation characters must be ignored, so there is no need
to throw them back, just adding the special case is enough?
Attached a patch which adds the rule and just sends the found word, plus a
test script which also exercises this particular case.
Note anyway that it is not necessarily what people may intend when using a
continuation:
foo\
bla
might mean "foobla" rather than "foo" then "bla". For instance with bash:
sh>ec\
> ho 1
1
But the same trick in python gives a syntax error:
py> print\
... (1)
1 # ok...
py> pri\
... nt(1)
File "<stdin>", line 2
nt(1)
^
SyntaxError: invalid syntax
I think it fine if pgbench behaves as python.
--
Fabien.
Commits
-
Allow backslash line continuations in pgbench's meta commands.
- cdc2a70470bd 10.0 landed