|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|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|