From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [GENERAL] aggregate returning anyarray and 'cannot determine result data type' |
Date: | 2014-04-23 14:07:33 |
Message-ID: | 22050.1398262053@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
I wrote:
> 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.
After sleeping on it, I'm convinced that this was an oversight that
we should fix before 9.4 ships. The code changes should be pretty
minimal; the executor in particular probably needs *less* code to
do this in a uniform way.
> 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?
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.
The best naming idea I've got right now is "finalfunc_extra" and
"mfinalfunc_extra", but maybe somebody can do better?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kalai R | 2014-04-23 15:14:46 | Re: About Large object Storage |
Previous Message | Tom Lane | 2014-04-23 13:41:26 | Re: About Large object Storage |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-04-23 14:17:48 | Re: Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation) |
Previous Message | Alvaro Herrera | 2014-04-23 14:02:51 | Re: Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation) |