Re: pgbench - allow backslash-continuations in custom scripts

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

In response to

Responses

Browse pgsql-hackers by date

  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