Re: appendBinaryStringInfo stuff - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: appendBinaryStringInfo stuff
Date
Msg-id 525fe2f7-2224-a5aa-16af-b1871fa38d0b@enterprisedb.com
Whole thread Raw
In response to Re: appendBinaryStringInfo stuff  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: appendBinaryStringInfo stuff  (David Rowley <dgrowleyml@gmail.com>)
Re: appendBinaryStringInfo stuff  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
On 19.12.22 23:48, David Rowley wrote:
> On Tue, 20 Dec 2022 at 11:42, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think Peter is entirely right to question whether *this* type's
>> output function is performance-critical.  Who's got large tables with
>> jsonpath columns?  It seems to me the type would mostly only exist
>> as constants within queries.
> 
> The patch touches code in the path of jsonb's output function too. I
> don't think you could claim the same for that.

Ok, let's leave the jsonb output alone.  The jsonb output code also 
won't change a lot, but there is a bunch of stuff for jsonpath on the 
horizon, so having some more robust coding style to imitate there seems 
useful.  Here is another patch set with the jsonb changes omitted.

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [BUG] pg_upgrade test fails from older versions.
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Force streaming every change in logical decoding