Hello Peter,
On 5/24/17 03:14, Fabien COELHO wrote:
I've improved it in attached v11:
- add a link to the CASE full documentation
- add an example expression with CASE ...
This patch needs (at least) a rebase for the upcoming commit fest.
Here is a rebase.
It still passes my tests.
From my point of view this patch is mostly ok, after 16 months in the
pipe.
ISTM that it is not tagged "ready" because there should be tap tests
attached. However the current tap tests in pgbench are very poor,
basically nothing at all is tested. There is a patch
(https://commitfest.postgresql.org/14/1118/) also submitted for adding a
significant tap test infrastructure, and if it gets through the idea is to
update this operator patch to cover the different new functions and
operators. It could be done in reverse order also, i.e. if the operator
patch get through the tap test patch would be updated to also test the new
functions and operators. The status of the tap-test patch is that it
really needs to be tested on Windows.
Note that someone might object that they do not need these operators and
functions in pgbench so they are useless, hence the patch should be
rejected. My answer is that standard benchmarks, eg TPC-B, actually use
these operator classes (bitwise, logical, ln...) so they are needed if
pgbench is to be used to implement said benchmarks. And if this is not
desirable, then what is the point of pgbench?
A renew interest is that "\if" commands have recently been added to
"psql", an "\if" calls for logical expressions, so a next step would be to
move the expression capability as a shared tool in front-end utils so that
it may be used both by "pgbench" and "psql". Also, I'll probably submit an
"\if" extension to pgbench backslash command language, as it is also
definitely a useful tool in a benchmark script.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
