From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sharing aggregate states between different aggregate functions |
Date: | 2015-07-28 16:18:53 |
Message-ID: | 25301.1438100333@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnaka(at)iki(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2015-07-28 16:46:38 | Re: proposal: multiple psql option -c |
Previous Message | Joe Conway | 2015-07-28 16:16:58 | Re: more RLS oversights |