> 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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers