Re: extend pgbench expressions with functions - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: extend pgbench expressions with functions
Date
Msg-id alpine.DEB.2.10.1512211604110.8529@sto
Whole thread Raw
In response to Re: extend pgbench expressions with functions  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: extend pgbench expressions with functions
List pgsql-hackers
Hello Michael,

>> I'm not sure whether we are talking about the same thing:
>>  - there a "double" type managed within expressions, but not variables
>>  - there is a double() function, which takes an int and casts to double
>>
>> I understood that you were suggesting to remove all "double" expressions,
>> but now it seems to be just about the double() function.
>
> There is indeed a misunderstanding here: I meant from the start the
> removal of only the "double" function.

Ok. I clearly misunderstood everything...

> It would be nice to keep as user-visible only things that have some 
> meaning.

Why not.

The purpose of some of these functions what to show how the function 
infrastructured extended, as was asked on the thread. The really useful 
ones in the bunch are the arithmetic operators and randoms generators.

> [...] Well, if there were doubles as return results really allocated as 
> doubles in variables having both would make sense. And honestly 
> something like sqrt that returns an integer when allocated in a variable 
> is really surprising.. And as you mentioned upthread there is no real 
> meaning to have doubles variable types that can be allocated.

So you would just like to remove double double(int) and double 
sqrt(double) from the patch, and basically that is all? int int(double)??
debug??? (hmmm, useful debugging a non trivial expression).

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Paul Ramsey
Date:
Subject: Re: Parallel Aggregate
Next
From: Artur Zakirov
Date:
Subject: Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types