Stephen Frost <sfrost@snowman.net> writes:
>>> Additionally, we'd have to be
>>> able to mark the types as being polymorhpic along the same lines as
>>> anyelement/anyarray.
>>
>> What for?
> So that the finalfunc can be polymorphic along the lines of my suggested
> aaccum_sfunc(anyarray,anyelement) returns anyarray and
> aaccum_ffunc(anyarray) returns anyarray.
Hmm ... there's not any real need for this at the level of the
aggregate, because we resolve a polymorphic aggregate's output type
directly from its input type(s), and we've already established that the
general-purpose agg code doesn't need to be able to infer anything about
the transition data type. However the function code is going to
complain if you try to declare "my_sfunc(aggregate_state) returns
anyarray" because that looks ill-formed ... and indeed that kinda kills
the idea of being able to call my_sfunc standalone anyway.
Maybe we need a more radical solution in which the sfunc/ffunc don't
exist as separately callable entities at all. That would sidestep the
whole need to have a type-system representation for the state data,
as well as eliminate worries about whether we've sufficiently plugged
the security risks of being able to call one of them in an unexpected
context. Not sure what this should look like in the catalogs though.
regards, tom lane