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.
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 |