Re: pgbench - allow backslash-continuations in custom scripts

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: pgbench - allow backslash-continuations in custom scripts
Дата
Msg-id 5584602D.6090904@agliodbs.com
обсуждение исходный текст
Ответ на pgbench - allow backslash-continuations in custom scripts  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: pgbench - allow backslash-continuations in custom scripts
Re: pgbench - allow backslash-continuations in custom scripts
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: The real reason why TAP testing isn't ready for prime time
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: pretty bad n_distinct estimate, causing HashAgg OOM on TPC-H