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: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: extend pgbench expressions with functions
Date: 2015-12-21 15:16:52
Message-ID: alpine.DEB.2.10.1512211604110.8529@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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).


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Artur Zakirov 2015-12-21 15:21:08 Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types
Previous Message Paul Ramsey 2015-12-21 15:16:19 Re: Parallel Aggregate