From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench - allow backslash-continuations in custom scripts |
Date: | 2015-06-19 18:32:13 |
Message-ID: | 5584602D.6090904@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/14/2015 12:10 PM, Fabien COELHO wrote:
>
> Add backslash continuations to pgbench custom scripts.
>
> The benefit of this approach is that it is upward compatible, and it is
> also pretty simple to implement. The downside is that backslash
> continuation is not the best syntax ever invented, but then you do not
> have to use it if you do not like it.
>
> The alternative would be to make semi-colon a mandatory end-of-line
> marker, which would introduce an incompatibility and requires more
> efforts to implement, including some kind of SQL-compatible lexer.
>
> IMHO this approach is the best compromise.
I don't personally agree. I believe that it it worth breaking backwards
compatibility to support line breaks in pgbench statements, and that if
we're not going to do that, supporting \ continuations is of little value.
As someone who actively uses pgbench to write custom benchmarks, I need
to write queries which I can test. \ continuation does NOT work on the
psql command line, so that's useless for testing my queries; I still
have to reformat and troubleshoot. If we added \ continuation, I
wouldn't use it.
I think we should support line breaks, and require semicolons for
end-of-statement. Backwards-compatability in custom pgbench scripts is
not critical; pgbench scripts are neither used in produciton, nor used
in automated systems much that I know of.
I'm not clear on why we'd need a full SQL lexer.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2015-06-19 18:32:53 | Re: pretty bad n_distinct estimate, causing HashAgg OOM on TPC-H |
Previous Message | Tom Lane | 2015-06-19 18:26:56 | Re: The real reason why TAP testing isn't ready for prime time |