Re: Sharing aggregate states between different aggregate functions

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

In response to

Responses

Browse pgsql-hackers by date

  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