Re: [GENERAL] aggregate returning anyarray and 'cannot determine result data type'

[ redirecting to -hackers ]

Tomas Vondra <tv@fuzzy.cz> writes:
> So my plan was to do something like this:

>   sample_append(internal, anyelement, int) -> internal
>   sample_final(internal) -> anyarray

>   CREATE AGGREGATE sample_agg(anyelement, int) (
>       SFUNC = sample_append,
>       STYPE = internal,
>       FINALFUNC = sample_final
>   );

> However this leads to
>   ERROR:  cannot determine result data type
>   DETAIL:  A function returning a polymorphic type must have at least
>            one polymorphic argument

> because 'sample_final' produces anyarray but has no polymorphic
> argument.

Yeah, this is a problem with trying to use internal stype for polymorphic
aggregates.

The same problem came up in connection with the "ordered set" aggregates
that were added recently, and that patch implemented an interesting
workaround: the final function for an OSA gets additional dummy arguments
of the same type as the aggregate inputs.  They are always passed as NULLs
at runtime, and have no real value except if the aggregate is polymorphic
--- but when it is, they provide a way to resolve the result type of a
polymorphic final function, even if the state type is "internal" or
otherwise non-polymorphic.

I thought at the time that maybe we should offer this feature for regular
aggregates as well as ordered-set ones, but didn't do anything about
it because there hadn't been demand.  If we did have it, you could solve
this problem with
 sample_append(internal, anyelement, int) -> internal sample_final(internal, anyelement, int) -> anyarray
 CREATE AGGREGATE sample_agg(anyelement, int) (     SFUNC = sample_append,     STYPE = internal,     FINALFUNC =
sample_final);
 

where sample_final would have to be declared non-strict (since it'd always
be getting some NULL arguments), but that's a small price to pay.

I think it'd be a pretty small adjustment to the already-committed
code to allow this to happen.  Basically we'd just have to decouple
the extra-arguments-to-finalfn behavior from ordered-set aggregates.

One potential issue though is that if sample_final existed in both
signatures it wouldn't be very clear which one got selected for the
aggregate.  Perhaps the best fix would be to invent a different
CREATE AGGREGATE keyword for finalfns with extra arguments?  If
so, that's something we ought to do *now*, not in 9.5, because
it'll be too late to redefine how to create OSAs once 9.4 ships.

Thoughts?
        regards, tom lane