Re: Properly handling aggregate in nested function call - Mailing list pgsql-general

From Matt Magoffin
Subject Re: Properly handling aggregate in nested function call
Date
Msg-id 45CF47FB-A07A-44C5-9559-9C731B917967@msqr.us
Whole thread Raw
In response to Re: Properly handling aggregate in nested function call  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On 15/12/2021, at 11:51 AM, Tom Lane <tgl@sss.pgh.pa.us> 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 (i.e. the length of the first input array) and enforced there [1] so I can stuff away here.

You should
probably palloc temp arrays right here and then use construct_md_array
directly instead of dealing with an ArrayBuildState.

OK, I can try that out. I did have another branch where I create the ArrayBuildState in this final function [2] but I still got the same result. I’ll try using construct_md_array instead as you suggest, thank you.

Also, I wonder what happens when state->vec_counts[i] is zero.
That's seemingly not your problem right now, since the ereport(NOTICE)
is being reached; but it sure looks like trouble waiting to happen.

It can happen, but the ArrayBuildState is initialised with all astate->dnulls[i] as true at the start [3], so the 

if (state->vec_counts[i]) {
}

test just skips those elements and leaves them as NULL.

— m@

pgsql-general by date:

Previous
From: Bèrto ëd Sèra
Date:
Subject: Re: Best Strategy for Large Number of Images
Next
From: "David G. Johnston"
Date:
Subject: Re: Why can't I have a "language sql" anonymous block?