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
Tomas Vondra t...@fuzzy.cz writes:
On 25.4.2014 23:26, Tom Lane wrote:
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
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.
The best naming idea I've got
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
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
[ redirecting to -hackers ]
Tomas Vondra t...@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 =
