Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> On 10 April 2014 15:18, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This idea of a separate firsttrans function is interesting but perhaps
>> orthogonal to the current patch. Also, I don't quite understand how
>> it would work for aggregates with null initvalues; don't you end up
>> with exactly the same conflict about how you can't mark the transfn
>> strict? Or is the idea that firsttrans would *only* apply to aggregates
>> with null initvalue, and so you wouldn't even pass the previous state
>> value to it?
> I was imagining that firsttrans would only be passed the first value
> to be aggregated, not any previous state, and that it would be illegal
> to specify both an initcond and a firsttrans function.
Got it. So the existing behavior where we insert the first non-null
value could be seen as a degenerate case in which the firsttrans function
is an identity.
> The forward transition function would only be called for values after
> the first, by which point the state would be non-null, and so it could
> be made strict in most cases. The same would apply to the invertible
> transition functions, so they wouldn't have to do null counting, which
> in turn would make their state types simpler.
Makes sense to me. We need names for these things though. I don't
think abbreviating to "ffunc" is a good idea because of the likelihood
of confusion with the finalfunc (indeed I see the CREATE AGGREGATE
ref page is already using "ffunc" as a short form for finalfunc).
Maybe "initfunc", which would parallel "initcond"?
What about names for the invertible-aggregate infrastructure?
I'm tempted to prefix "inv" to all the existing names, but then
"invsfunc" means the alternate forward function ... can we use
"invifunc" for the inverse transition function? Or maybe the
prefix should be just "i".
regards, tom lane