Re: improve pgbench syntax error messages

Hello,

Here is a v5.

>> While adding a basic function call syntax to expressions, a noticed that it
>> would be useful to access the "detail" field of syntax errors so as to
>> report the name of the unknown function. This version just adds the hook
>> (expr_yyerror_detailed) that could be called later for this purpose.
>
> Let's not add code that isn't doing anything yet. We can patch the
> system more later if we need to.

Ok.

> +/* better error reporting with bison */
> +%define parse.lac full
> +%define parse.error verbose
>
> What does this do?

It adds an explanation on syntax errors, instead of the laconic "syntax
error" which is akin to a boolean.

> The comments should explain, I think.

I thought it did with the sentence "better error reporting with bison".

> Does it work on all versions of bison >= the minimum version we support?

Good question. After some digging, it seems to be 1.85 since pg 7.4... It
does not seem to have a '%define' directive yet. That's too bad, because I
like the better messages. So I put the define in a comment.

Maybe some conditional activation from configure generated macro could be
possible, but I did not find anything about bison version.

> +void syntax_error(const char *source, const int lineno,
> + if (line) {
>
> Not project style.

Indeed.

> How about having syntax_error using appendPQExpBuffer() and friends
> instead of printing data one character at a time?

This is just a basic error message printed before exiting. The simpler and
more straightforward the better, IMHO. Pgbench relies on basic
"fprintf(stderr, ...)" for error messages everywhere, I tried to blend in,
eg I avoided "fputc" for printing alignment spaces for instance. PQ buffer
stuff is not used anywhere else in pgbench. It seems to me overkill to
introduce it there just for this function. I'll do it only if required.

> +/* error message generation helper */
> +#define SYNTAX_ERROR(msg, more, col) \
> + syntax_error(source, lineno, my_commands->line, \
> + my_commands->argv[0], msg, more, col)
> +
>
> I don't like this. Just substitute the expansion. Otherwise there's
> a non-obvious dependency on my_commands.

I wanted to have one line calls and to avoid repeating the same list of
arguments over and over again, especially with the very long "my_commands"
variable name.

Once expanded, the result is either two long lines or three
under-80-column lines per call. Not sure which one of these ugly choices
is best. I took the first option.

> + /* stop "set" argument parsing the variable name */
>
> This comment addition isn't related to the purpose of this patch, and
> I also can't understand what the new comment is supposed to mean.
> It's the value we don't want to strtok()-ify, not the name.

I wanted to write: "stop set argument parsing after the variable name"
(I forgot "after") because I had to figure out the max_args management
and a minimal comment would have helped. Maybe not with this comment
though. I removed it.

--
Fabien.