Re: Sharing aggregate states between different aggregate functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Sharing aggregate states between different aggregate functions
Date
Msg-id 25301.1438100333@sss.pgh.pa.us
Whole thread Raw
In response to Re: Sharing aggregate states between different aggregate functions  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Sharing aggregate states between different aggregate functions  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 07/28/2015 04:14 AM, David Rowley wrote:
>> I'd not thought of an input function being volatile before, but I guess
>> it's possible, which makes me a bit scared that we could be treading on
>> ground we shouldn't be. I know it's more of an output function thing than
>> an input function thing, but a GUC like extra_float_digits could cause
>> problems here.

GUC dependence is considered to make a function stable not volatile.
(I realize you can probably break that if you try hard enough, but
then you get to keep both pieces.)

> Yeah, a volatile input function seems highly unlikely, but who knows. 

We have a project policy against volatile I/O functions.  One reason why
is that it would break the assumption that record_in/record_out can be
marked stable.  I think there are other reasons too.

> BTW, we're also not checking if the transition or final functions are 
> volatile. But that was the same before this patch too.

Up to now it hasn't mattered.  Possibly this patch should refuse to
combine states across volatile transition functions?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: more RLS oversights
Next
From: Andrew Dunstan
Date:
Subject: Re: proposal: multiple psql option -c