Re: [HACKERS] pgbench - allow backslash continuations in \setexpressions
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] pgbench - allow backslash continuations in \setexpressions |
Дата | |
Msg-id | alpine.DEB.2.20.1701201341310.2145@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] pgbench - allow backslash continuations in \set expressions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] pgbench - allow backslash continuations in \set expressions
|
Список | pgsql-hackers |
> 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
Вложения
В списке pgsql-hackers по дате отправления: