Hello Robert,
Advertising
For example, I just realized that this patch allows values to be
either a double or an integer and extends the operators to handle
double values. But variables can still only be integers.
Indeed.
[...] at least flatten everything to string rather than integer so that
you can store the value without loss of precision - just with loss of
type-safety. I think designing this in this way is quite short-sighted.
Note that I'm not responsible for this design, which is preexisting.
Extending variables to be able to store doubles could also be done in
another patch.
I don't think variables should be explicitly typed but they should be
able to store a value of any type that expression evaluation can
generate.
Doubles are not really needed that much, it is just to provide something
to random_* functions parameter, otherwise it is useless as far as pgbench
is really concerned.
Also, as I said back in November, there's really two completely
separate enhancements in here. One of them is to support a new data
type (doubles) and the other is to support functions.
Yep. The first part is precisely the patch I initially submitted 5 CF ago.
Then I'm asked to put more things in it to show that it can indeed handle
another type. Then I'm told "you should not have done that". What can I
say?
Those should really be separate patches.
They could.
[...] I find implementing operators as functions in disguise not to be
one of PostgreSQL's most awesome design decisions, and here we are
copying that into pgbench for, well, no benefit that I can see, really.
Well, I did that initially, then I was asked to implements operators as
functions. It probably saves some lines, so it is not too bad, even if the
benefit is limited.
Maybe it's a good idea and maybe it's a bad idea, but how do we know?
This is just pgbench, a tool for testing performance by running dummy
transactions, not a production thing, so I think that it really does not
matter. There is no user visible changes wrt operators.
[...] If neither of you are willing to split this patch, I'm not willing
to commit it.
If I'm reading you correctly, you would consider committing it:
- if the function & double stuff are separated ?
- for the double part, if variables can be double ?
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
