Re: PATCH: pgbench allow '=' in \set

On Thu, May 14, 2015 at 3:20 AM, Fabien COELHO
<fabien.coelho@mines-paristech.fr> wrote:
>> I loathe violently the convention of using a backslash at the end of a
>> line, because it's too easy to write backslash-space-newline or
>> backslash-tab-newline when you meant to write backslash-newline. But maybe
>> we should do it anyway.  We certainly need some solution to that problem,
>> because the status quo is monumentally annoying, and that might be the least
>> bad solution available.
>
> I survive with that in bash/make/python...

Yeah.

>> Another option, breaking backward compatibility, would be to decide
>> that backslash commands have to be terminated by a semicolon token.
>
> I do not like it much, as it is inconsistent/incompatible with "psql".

True, but anything will be, as far as backslash commands are
concerned.  psql doesn't support continuation lines in backslash
commands at all.

>> [...] multi-line SQL queries.  If we wanted to make that work, the best
>> option might be to duplicate the backend lexer into pgbench just as we
>> already do with psql. [...]
>>
>> I somewhat lean toward this second option, because I think it will be
>> a lot more convenient in the long run.  We'll probably get some
>> complains about breaking people's pgbench scripts, but I'd personally
>> be prepared to accept that as the price of progress.
>
> For an actual lexer: currently there is no real lexer for SQL commands in
> pgbench, the line is just taken as is, so that would mean adding another
> one, although probably a simplified one would do.

I think what we'd do is extend the expression lexer to cover
everything in the file.

> To conclude, I'm rather for continuations, despite their ugliness, because
> (1) it is much easier (just a very small change in read_line_from_file) and
> (2) it is backward compatible, so no complaints handle.

Those are certainly points to consider.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company