Hello Rafia,
Please keep copying to the list.
> Though I find the first version of this patch acceptable in terms that it
> would be helpful on enhancing the readability of expressions as you
> mentioned. However, the second version is not clear as I mentioned before
> also, there has to be detailed documentation regarding this, still as an
> end-user one needs to be too careful to decide which statements to split
> lines based on the patch, for example following
> \set bid
> CASE WHEN random(0, 99) < 85
> THEN :tbid
> ELSE :abid + (:abid >= :tbid)
> END
>
> should be written as
>
> \set bid CASE WHEN random(0, 99) < 85
> THEN :tbid
> ELSE :abid + (:abid >= :tbid)
> END
I do not understand the "should". It is a matter of style, and both cases
would work with the second version of the patch.
> (and a few more variants of splitting lines just after an operator or
> open parenthesis) which does not look like much enhancement in
> readability to me.
As I said, I will not fight over this one. I like inferred continuations
in scala, but I guess it would be surprising for such an old school script
like pgbench, and it would be hard to do that consistently for pgsql
because the backslash command syntax may depends on the command itself (eg
does it have to respect strings and parenthesis, or some other
structures...).
> So this patch needs to add the support to read the next line even when
> "\set a" and other such similar expressions are encountered.
The scala convention is that if the line is not finished the user must
either use explicit parenthesis are use an unambiguous operator which
expects an operand, so that the lexer knows it has to go on.
I do not think that having both inferred continuations and explicit
backslash continuations is desirable, it should be one or the other.
--
Fabien.