Florian Pflug <fgp@phlo.org> writes:
> Which is why I feel that having two separate sets of transition functions
> and state types solves the wrong problem. If we find a way to prevent
> transition functions from being called directly, we'll shave a few cycles
> of quite a few existing aggregates, invertible or not. If we find a way
> around the initfunc-for-internal-statetype problem you discovered, the
> implementation would get much simpler, since we could then make nearly
> all of them strict. And this would again shave off a few cycles - for lots
> of NULL inputs, the effect could even be large.
Since neither of those latter things seems likely to happen, I don't
find this argument convincing at all. Even if they did happen, they
would represent an incremental improvement that would be equally useful
with either one or two sfuncs.
Basically, this comes down to a design judgment call, and my judgment
is differing from yours. In the absence of opinions from others,
I'm going to do it my way.
However, quite independently of how many sfuncs there are, I'm interested
about this:
> ... SUM(int4) wouldn't need
> *any* extra state at all to be invertible, if it weren't for those pesky
> issues surrounding NULL handling. In fact, an earlier version of the
> invtrans patch *did* use int4_sum as SUM(int4)'s transfer functions! The
> only reason this doesn't work nowadays is that Dean didn't like the
> forward-nonstrict-but-inverse-strict special case that made this work.
Tell me about the special case here again? Should we revisit the issue?
regards, tom lane