From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: appendBinaryStringInfo stuff |
Date: | 2022-12-23 09:04:33 |
Message-ID: | 525fe2f7-2224-a5aa-16af-b1871fa38d0b@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 19.12.22 23:48, David Rowley wrote:
> On Tue, 20 Dec 2022 at 11:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 | Content-Type | Size |
---|---|---|
v2-0001-Use-appendStringInfoString-instead-of-appendBinar.patch | text/plain | 5.6 KB |
v2-0002-Change-argument-of-appendBinaryStringInfo-from-ch.patch | text/plain | 5.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2022-12-23 09:12:18 | RE: Force streaming every change in logical decoding |
Previous Message | Michael Paquier | 2022-12-23 08:51:28 | Re: [BUG] pg_upgrade test fails from older versions. |