On 16/12/2021, at 2:43 PM, Tom Lane wrote:
> Of course what this function is actually returning is numeric[].
> There is some code such as array_out that will look at the
> element type OID embedded in the array value, and do the right
> thing. But other code will believe the function's declared
Matt Magoffin writes:
> Any other ideas I could look into?
Per the old saw, when you can't see the problem, it usually means
you're looking in the wrong place. I looked at the SQL declaration
of the function [1], and saw:
CREATE OR REPLACE FUNCTION
vec_agg_mean_finalfn(internal)
RETURNS bigint[
On 15/12/2021, at 11:51 AM, Tom Lane wrote:
> You should
> probably palloc temp arrays right here and then use construct_md_array
> directly instead of dealing with an ArrayBuildState.
OK, I gave that a go [1] this time in a vec_agg_sum() aggregate, that operates
much the same as the vec_agg_mea
On 15/12/2021, at 11:51 AM, Tom Lane wrote:
> Hmm, I think you're abusing the ArrayBuildState API. In particular,
> what guarantees that the astate->dvalues and astate->dnulls arrays
> are long enough for what you're stuffing into them?
The length is defined in the aggregate transition function
Matt Magoffin writes:
> Any ideas what I’m doing wrong here? The source is available here:
> https://github.com/SolarNetwork/aggs_for_vecs/blob/9e742cdc32a113268fd3c1f928c8ac724acec9f5/vec_agg_mean.c
Hmm, I think you're abusing the ArrayBuildState API. In particular,
what guarantees that the as
