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. -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers