Stephen Frost <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org