From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: extend pgbench expressions with functions |
Date: | 2015-12-19 11:40:37 |
Message-ID: | CAB7nPqSwGSde5mvrQEmTi0cfdAVdPmzP6y4o6Z8bBV=D916WUw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Dec 19, 2015 at 6:56 AM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>> It was definitely useful to debug the double/int type stuff within
>> expressions when writing a non trivial pgbench script. It is probably less
>> interesting if there are only integers.
>
>
> After looking again at the code, I remembered why double are useful: there
> are needed for random exponential & gaussian because the last parameter is a
> double.
>
> I do not care about the sqrt, but double must be allowed to keep that, and
> the randoms are definitely useful for a pgbench script. Now the patch may
> just keep double constants, but it would look awkward, and the doc must
> explain why 1.3 and 1+2 are okay, but not 1.3 + 2.4.
>
> So I'm less keen at removing double expressions, because it removes a key
> feature. If it is a blocker I'll go for just the constant, but this looks to
> me like a stupid compromise.
Hm, say that you do that in a script:
\set aid double(1.4)
\set bid random_gaussian(1, 10, :aid)
Then what is passed as third argument in random_gaussian is 1, and not
1.4, no? If all allocations within a variable are unconditionally
integers, why is it useful to make the cast function double()
user-visible? Now, by looking at the code, I agree that you would need
to keep things like DOUBLE and coerceToDouble(),
PGBENCH_RANDOM_GAUSSIAN and its other friend are directly using it. I
am just doubting that it is actually necessary to make that visible at
user-level if they have no direct use..
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2015-12-19 11:44:52 | Re: Fuzzy substring searching with the pg_trgm extension |
Previous Message | Michael Paquier | 2015-12-19 10:11:18 | Re: Making tab-complete.c easier to maintain |