Re: extend pgbench expressions with functions

On Thu, Dec 17, 2015 at 6:02 PM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>> Really, I like this patch, and I think that it is great to be able to
>> use a set of functions and methods within a pgbench script because
>> this clearly can bring more clarity for a developer, still it seems
>> that this patch is trying to do too many things at the same time:
>> 1) Add infrastructure to support function calls and refactor the
>> existing functions to use it. This is the FUNCTION stuff in the
>> expression scanner.
>> 2) Add the concept of double return type, this could be an extension
>> of \set with a data type, or a new command like \setdouble. This
>> should include as well the casting routines I guess. This is the
>> DOUBLE stuff in the expression scanner.
>> 3) Introduce new functions, as needed.
>
>
> Yep. I started with (1), and was *ASKED* to do the others.

That's the beginning of the thread... N developers have (N+1) opinions
as a wise guy watching this mailing list said once.

>> 1) and 2) seem worthwhile to me. 3) may depend on the use cases we'd
>> like to have.. sqrt has for example value if a variable can be set
>> double as a double type.
>
>
> Sure. This is just an example of a double function so that if someone wants
> to add another one they can just update where it make sense. Maybe log/exp
> would make more sense for pgbench.

Perhaps..

>> In conclusion, for this CF the patch doing the documentation fixes is
>> "Ready for committer", the second patch introducing the function
>> infrastructure should focus more on its core structure and should be
>> marked as "Returned with feedback". Opinions are welcome.
>
>
> My opinion is that to do and undo work because of random thoughts on the
> list is tiring.
>
> What I can do is:
>
> (1) fix the doc and bugs if any, obviously.

Thanks.

> (2a) remove double stuff, just keep integer functions.
> I would rather keep min/max, though.

(2a) sounds like a fine plan to get something committable. We could
keep min/max/abs, and remove sqrt/pi. What's actually the use case for
debug? I cannot wrap my mind on one?

> (2b) keep the patch with both int & double as is.

Functions returning double are not that useful... pgbench can live without them.

> What I will *NOT* do is to add double variables without a convincing use
> case.

I am not actually meaning that you should do it. I scrutinized the
thread and this patch and thought that there could be perhaps be some
use cases for double return values after seeing the cast functions. It
is not my attention to piss you off, I like this patch a lot, and you
have already proved that if someone wanted to get those additional
features, well the infrastructure being put in place would allow doing
that :)
If the second patch gets in a simplified shape I'll look at it again
then let's move on with a committer's opinion.

Regards,
--
Michael