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