Re: Avoiding memory leakage in jsonpath evaluation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Avoiding memory leakage in jsonpath evaluation
Date
Msg-id 1293329.1773935249@sss.pgh.pa.us
Whole thread Raw
In response to Re: Avoiding memory leakage in jsonpath evaluation  (Chao Li <li.evan.chao@gmail.com>)
List pgsql-hackers
Chao Li <li.evan.chao@gmail.com> writes:
> On Mar 19, 2026, at 00:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> BTW, I don't love the function name JsonValueListIsMultiple, but if
>> there's a common term analogous to "singleton" but describing sets
>> with more than one member, I don't know it.

> Maybe JsonValueListHasMultiple?
> If it were me, I might name them like this:
> * JsonValueListIsEmpty
> * JsonValueListHasOneItem
> * JsonValueListHasMultipleItems

I think JsonValueListIsSingleton is fine: it's a well-understood
term that appears in hundreds of other places in our tree.  I took
your suggestion of JsonValueListHasMultipleItems, though.

> One nitpick on 0002 is that, these three functions don’t modify jvl, so the parameter could be made const.

Yeah.  I'd left them like that because the pre-existing
JsonValueListIsEmpty() wasn't using const, but I agree it's
neater to do so.  Changed.

A related annoyance is that I had to remove "const" from the
JsonValueList parameters of JsonValueListInitIterator and
wrapItemsInArray.  That's because JsonValueListNext returns
not-const JsonbValue *, and my compiler complained (rightly)
that returning a pointer into the embedded items[] array would
be casting away const.  It's conceivable that we could change
JsonValueListNext to return const JsonbValue *.  But that would
require wholesale const-ification of a lot of calling code, and
I judged it not worth the trouble, or at least material for a
different patch.

Pushed with those changes.  Thanks for reviewing!

            regards, tom lane



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Feature freeze timezone change request
Next
From: Nathan Bossart
Date:
Subject: Re: another autovacuum scheduling thread