Hello Robert,
I am not objecting to the functionality; I'm objecting to bolting on
ad-hoc operators one at a time. I think an expression syntax would
let us do this in a much more scalable way. If I had time, I'd go do
that, but I don't. We could add abs(x) and hash(x) and it would all
be grand.
Ok. I do agree that an expression syntax would be great!
However, that would not diminish nor change much the amount and kind of
code necessary to add an operator or a function: the parser would have to
be updated, and the expression structure, and the executor. Currently the
pgbench "parser" and expression are very limited, but they are also very
generic so that nothing is needed to add a new operator there, only the
execution code needs to be updated, and the update would be basically the
same (if this is this function or operator, actually do it...) if the
execution part of a real expression syntax would have to be updated.
So although I agree that a real expression syntax would be great "nice to
have", I do not think that it is valid objection to block this patch.
Moreover, upgrading pgbench to handle an actual expression syntax is not
so trivial, because for instance some parts of the text needs to be parsed
(set syntax) while others would need not to be pased (SQL commands), so
some juggling would be needed in the lexer, or maybe only call the parser
on some lines and not others... Everything is possible, but this one would
require some careful thinking.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
