From: Tom Lane <tgl@sss.pgh.pa.us>
To: jian he <jian.universality@gmail.com>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Making jsonb_agg() faster
In-reply-to: 
 <CACJufxHuE-P0s1PxiRja26ZMjKUZiCAgWa1jedswo94SFzjXMg@mail.gmail.com>
References: <1060917.1753202222@sss.pgh.pa.us>
 <CACJufxHuE-P0s1PxiRja26ZMjKUZiCAgWa1jedswo94SFzjXMg@mail.gmail.com>
Comments: In-reply-to jian he <jian.universality@gmail.com>
	message dated "Thu, 14 Aug 2025 16:59:56 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <617665.1755277022.1@sss.pgh.pa.us>
Date: Fri, 15 Aug 2025 12:57:02 -0400
Message-ID: <617666.1755277022@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/617666.1755277022%40sss.pgh.pa.us>
Precedence: bulk

jian he <jian.universality@gmail.com> writes:
> outcontext will always be NULL in 0001.
> that means copyScalarSubstructure is never really called.
> it also means that JsonbInState->MemoryContext  was always as NULL in 00001
> maybe we don't need JsonbInState->MemoryContext in 0001
> So 0001 refactoring change would be less invasive.

I think you're missing the point: per the commit message for 0001,

    The real reason for doing it is to provide a mechanism whereby
    pushJsonbValue() can be told to construct the JsonbValue tree
    in a context that is not CurrentMemoryContext.  That happens
    when a non-null "outcontext" is specified in the JsonbInState.
    No callers exercise that option in this patch, but the next
    patch in the series will make use of it.

If we didn't add the outcontext option in this step, we'd just
have to do so in the next one.

			regards, tom lane