From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, pgsql-hackers(at)postgresql(dot)org, n(dot)gluhov(at)postgrespro(dot)ru |
Subject: | Re: JSON constructors and window functions |
Date: | 2022-04-04 16:21:32 |
Message-ID: | 20220404162132.iv4vraocljwihs5o@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-04-04 11:43:31 -0400, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > On 4/3/22 22:46, Andrew Dunstan wrote:
> >> On 4/3/22 20:11, Andres Freund wrote:
> >>> I don't think you're allowed to free stuff in a finalfunc - we might reuse the
> >>> transition state for further calls to the aggregate.
>
> >> Doh! Of course! I'll fix it in the morning. Thanks.
>
> > I've committed a fix for this. I didn't find something to clean out the
> > hash table, so I just removed the 'hash_destroy' and left it at that.
> > All the test I did came back with expected results.
> > Maybe a hash_reset() is something worth having assuming it's possible? I
> > note that simplehash has a reset function.
>
> But removing the hash entries would be just as much of a problem
> wouldn't it?
I think so. I guess we could mark it as FINALFUNC_MODIFY = READ_WRITE. But I
don't see a reason why it'd be needed here.
Is it a problem that skipped_keys is reset in the finalfunc? I don't know how
these functions work. So far I don't understand why
JsonUniqueBuilderState->skipped_keys is long lived...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2022-04-04 16:27:06 | Re: Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl? |
Previous Message | Mark Dilger | 2022-04-04 16:16:39 | Re: New Object Access Type hooks |