On 25.4.2014 23:26, Tom Lane wrote: > Tomas Vondra <t...@fuzzy.cz> writes: >> On 23.4.2014 16:07, Tom Lane wrote: >>> To be concrete: let's add a new boolean parameter with the >>> semantics of "final function takes extra dummy arguments" >>> (default false). There would need to be one for the separate >>> moving-aggregate final function too, of course. > >> Do we really need a separate parameter for this? Couldn't this be >> decided simply using the signature of the final function? Either >> it has a single parameter (current behavior), or it has the same >> parameters as the state transition function (new behavior). > > The problem is that the CREATE AGGREGATE syntax only specifies the > name of the final function, not its argument list, so you have to > make an assumption about the argument list in order to look up the > final function in the first place. > > I did consider the idea of looking for both signatures and using > whatever we find, but that seems fairly dangerous: the same CREATE > AGGREGATE command could give different results depending on what > versions of the final function happen to exist. This would create an > ordering hazard that pg_dump could not reliably cope with, for > example.
Yeah. And it wouldn't be clear which function to use in case two suitable functions (with different signatures) exist. So I guess this actually requires a parameter. I'd vote for "finalfunc_extra" - can't think of a better name, and I'm not sure what the "m" in "mfinalfunc_extra" stands for. regards Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
