Re: extend pgbench expressions with functions

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: extend pgbench expressions with functions
Date: 2016-02-13 14:41:08
Message-ID: alpine.DEB.2.10.1602131528150.3721@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Michaël,

>> - if the function & double stuff are separated ?
>> - for the double part, if variables can be double ?
>
> I just double-checked and could not see a clear use case mentioned in
> this thread for double return types,

Alas there is one: non uniform random functions which use a double
parameter.

Once random functions are there, the \setrandom horror code could be
removed, which would be a real benefit, IMO:-)

So I see a good case to have some support for doubles.

> so I would suggest focusing on the integer portion with min(), max(),
> abs(), debug() and the existing functions refactored. That's what your
> first versions did. If someone is wishing to implement double types,
> this someone could do it, the infrastructure that this patch puts in
> place has already proved that it can be easily extended.

Adding double is not too big a deal. I just stopped at variables because I
could not see any realistic use for them. My idea was to postpone that
till it is actually needed, "never" being the most probable course.

Now if this is a blocker for the committer, then I will probably make
the effort whatever I think of the usefulness of the feature.

--
Fabien.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-02-13 14:54:07 Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.
Previous Message Joshua D. Drake 2016-02-13 14:25:52 Re: Defaults for replication/backup