Hello Josh,
>> Add backslash continuations to pgbench custom scripts.
>> [...]
>> 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.
Attached is a "without lexer" version which does ;-terminated SQL commands
and \-continuated meta commands (may be useful for \shell and long \set
expressions).
Also attached is a small pgbench script to test the feature.
Without a lexer it is possible to fool pgbench with somehow contrived
examples, say with:
SELECT 'hello; world';
The ";" within the string will be considered as end-of-line.
Also, comments intermixed with sql on the same line would generate errors.
SELECT 1 -- one + 3;
Would fail, but comments on lines of their own are ok.
It may be argued that these are not a likely scripts and that this
behavior could be declared as a "feature" for keeping the code simple.
ISTM that it would be an overall improvement, but also the ;-termination
requirement breaks backward compatibility.
--
Fabien.