Horton

Re: appendBinaryStringInfo stuff

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: David Rowley <dgrowleyml@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-12-30T10:19:32Z
Lists: pgsql-hackers 
On 23.12.22 10:04, Peter Eisentraut wrote:
> 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.

I have committed these.

Commits

  1. Change argument type of pq_sendbytes from char * to void *

  2. Remove useless casts to (void *) in hash_search() calls

  3. Change argument of appendBinaryStringInfo from char * to void *

  4. Use appendStringInfoString instead of appendBinaryStringInfo where possible