Re: [HACKERS] pgbench - allow backslash continuations in \setexpressions - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] pgbench - allow backslash continuations in \setexpressions
Date
Msg-id alpine.DEB.2.20.1701201341310.2145@lancre
Whole thread Raw
In response to Re: [HACKERS] pgbench - allow backslash continuations in \set expressions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] pgbench - allow backslash continuations in \set expressions
List 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

Attachment

pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: [HACKERS] Improvements in psql hooks for variables
Next
From: Tom Lane
Date:
Subject: [HACKERS] Valgrind-detected bug in partitioning code