Re: PATCH: pgbench allow '=' in \set - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: PATCH: pgbench allow '=' in \set
Date
Msg-id alpine.DEB.2.10.1505140925080.454@sto
Whole thread Raw
In response to PATCH: pgbench allow '=' in \set  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: PATCH: pgbench allow '=' in \set
List pgsql-hackers
Hello Robert,

<Sorry resent, wrong from>

>> Also, having ";" as a end of commands could also help by allowing multiline
>> commands, but that would break compatibility. Maybe allowing continuations
>> (\\\n) would be an acceptable compromise.

> 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...

> 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".

> [...] 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.

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.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: upper planner path-ification
Next
From: Sawada Masahiko
Date:
Subject: Re: Proposal : REINDEX xxx VERBOSE