On 10 April 2014 19:04, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> On 10 April 2014 15:18, Tom Lane <t...@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. >
Right. >> 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"? > Yes, I was already thinking that "initfunc" is actually a much better name for that. > 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". > Hmm, I'm not a fan of any of those names. Perhaps "win" as a prefix to denote a sliding window? Or just "m" for "moving aggregate". Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
