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>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-12-30T10:25:23Z
Lists: pgsql-hackers 
On 23.12.22 14:01, David Rowley wrote:
> Maybe if there's concern that inlining appendStringInfoString is going
> to bloat the binary too much, then how about we just invent an inlined
> version of it using some other name that we can use when performance
> matters?  We could then safely replace the offending
> appendBinaryStringInfos from both places without any concern for
> regressing performance.

The jsonpath output routines don't appear to be written with deep 
concern about performance now, so I'm not sure this is the place to 
start tweaking.  For the jsonb parts, there are only a handful of 
strings this affects ("true", "false", "null"), so using 
appendBinaryStringInfo() there a few times doesn't seem so bad.  So I'm 
not too worried about this altogether.

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