Re: Rethinking representation of partial-aggregate steps

On 27 June 2016 at 08:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
>> On 27 June 2016 at 03:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Looking at this in the light of morning, I'm rather strongly tempted to
>>> invert the sense of the FINALIZE option, so that "simple" mode works out
>>> as zero, ie, select no options. Maybe call it SKIPFINAL instead of
>>> FINALIZE?
>
>> Aggref calls this aggpartial, and I was tempted to invert that many
>> times and make it aggfinalize, but in the end didn't.
>> It seems nicer to me to keep it as a list of things that are done,
>> rather than to make one exception to that just so we can have the
>> simple mode as 0.
>
> [ shrug... ] I do not buy that argument, because it doesn't justify
> the COMBINE option: why shouldn't that be inverted, ie USEFINALFUNC?
> The only way to decide that except by fiat is to say that we're
> enumerating the non-default or non-simple-mode behaviors.

hmm ok. I guess what exists today is there because I tried to make the
options "on" for additional tasks which aggregate must perform.
Whether to use transfunc or combine func is more of an alternative
than additional, so I have let what is standard tiebreak the decision
on which way around to have that flag. So perhaps you're right and we
should just normalise the flag to the standard aggregate behaviour to
keep it consistent.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services