Well with this new approach, the example you gave previously for better readability:
> \set bid > CASE WHEN random(0, 99) < 85 > THEN :tbid > ELSE :abid + (:abid >= :tbid) > END will give error at the first line. In general, this new approach is likely to create confusions in such cases. As an end-user one needs to be real careful to check what portions have to split between lines. Keeping this in mind, I'd prefer the previous approach. On Tue, Nov 1, 2016 at 4:23 PM, Fabien COELHO <coe...@cri.ensmp.fr> wrote: > > Attached patch does what is described in the title, hopefully. >> Continuations in other pgbench backslash-commands should be dealt with >> elsewhere... >> >> Also attached is a small test script. >> > > Here is another approach, with "infered" continuations: no backslash is > needed, the parsing is pursued if the last token of the line cannot end an > expression (eg an operator) or if there is an unclosed parenthesis. > > I think that backslashes are less surprising for the classically minded > user, but this one is more fun:-) Also, this version changes a little more > the scanner because on each token the next state (continued or not) must be > decided. > > -- > Fabien. > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > > -- Regards, Rafia Sabih EnterpriseDB: http://www.enterprisedb.com/
