On 07/02/2014 10:15 PM, Andrew Gierth wrote:
> (Had one request so far for a mode() variant that returns the unique
> modal value if one exists, otherwise null; so the current set of
> ordered-set aggs by no means exhausts the possible applications.)
I resemble that remark. :)
But seriously, am I
Andrew Gierth writes:
> Here are two more, cumulative with the previous patch and each other:
> The first removes the assumption in ordered_set_startup that the
> aggcontext can be cached in fn_extra, and puts it in the transvalue
> instead.
OK, done. (ATM it seems like we wouldn't need gcontext
> "Tom" == Tom Lane writes:
>> How's this? (applies and passes regression on 9.4 and master)
Tom> Pushed with minor cosmetic adjustments.
Thanks!
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> If we're going to do that, I think it needs to be in 9.4. Are
> Tom> you going to work up a patch?
> How's this? (applies and passes regression on 9.4 and master)
Pushed with minor cosmetic adjustments.
regard
Here are two more, cumulative with the previous patch and each other:
The first removes the assumption in ordered_set_startup that the
aggcontext can be cached in fn_extra, and puts it in the transvalue
instead.
The second exposes the OSA* structures in a header file, so that
user-defined ordered
> "Tom" == Tom Lane writes:
Tom> If we're going to do that, I think it needs to be in 9.4. Are
Tom> you going to work up a patch?
How's this? (applies and passes regression on 9.4 and master)
--
Andrew (irc:RhodiumToad)
diff --git a/src/backend/executor/nodeAgg.c b/src/backend/executo
> "Tom" == Tom Lane writes:
>> Do we want a decision on the fn_extra matter first, or shall I do
>> one patch for the econtext, and a following one for fn_extra?
Tom> I think they're somewhat independent, and probably best patched
Tom> separately. In any case orderedsetagg.c's use of fn
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> If we're going to do that, I think it needs to be in 9.4. Are
> Tom> you going to work up a patch?
> Do we want a decision on the fn_extra matter first, or shall I do one
> patch for the econtext, and a following one for fn_extra?
I th
> "Tom" == Tom Lane writes:
Tom> Another approach would be to remove AggGetPerAggEContext as such
Tom> from the API altogether, and instead offer an interface that
Tom> says "register an aggregate cleanup callback", leaving it to the
Tom> agg/window core code to figure out which context t
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Another approach would be to remove AggGetPerAggEContext as such
> Tom> from the API altogether, and instead offer an interface that
> Tom> says "register an aggregate cleanup callback", leaving it to the
> Tom> agg/window core code to
> "Tom" == Tom Lane writes:
>> Doing rollup via GroupAggregate by maintaining multiple transition
>> values at a time (one per grouping set) means that the transfn is
>> being called interleaved for transition values in different
>> contexts. So the question becomes: is it wrong for the t
Andrew Gierth writes:
> 1. Assumptions about the relationship between aggcontext and fn_extra
> Tom's version of the ordered-set aggregate code makes the assumption
> that it is safe to store the aggcontext returned by AggCheckCallContext
> in a structure hung off flinfo->fn_extra. This implicitl
I've been assisting Atri with development of an implementation of
GROUPING SETS, beginning with a one-pass implementation of ROLLUP.
Two issues have arisen regarding the API for calling aggregate
transition and final functions that I think need answering now,
since they relate to changes in 9.4.
1
13 matches
Mail list logo
