Re: appendBinaryStringInfo stuff
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-12-19T08:12:41Z
Lists: pgsql-hackers
Hi, On 2022-12-19 07:13:40 +0100, Peter Eisentraut wrote: > I found a couple of adjacent weird things: > > There are a bunch of places in the json code that use > appendBinaryStringInfo() where appendStringInfoString() could be used, e.g., > > appendBinaryStringInfo(buf, ".size()", 7); > > Is there a reason for this? Are we that stretched for performance? strlen() isn't that cheap, so it doesn't generally seem unreasonable. I don't think we should add the strlen overhead in places that can conceivably be a bottleneck - and some of the jsonb code clearly can be that. > I find this kind of code very fragile. But this is obviously an issue. Perhaps we should make appendStringInfoString() a static inline function - most compilers can compute strlen() of a constant string at compile time. Greetings, Andres Freund
Commits
-
Change argument type of pq_sendbytes from char * to void *
- 3b12e68a5c46 16.0 landed
-
Remove useless casts to (void *) in hash_search() calls
- 54a177a948b0 16.0 cited
-
Change argument of appendBinaryStringInfo from char * to void *
- 1f605b82ba66 16.0 landed
-
Use appendStringInfoString instead of appendBinaryStringInfo where possible
- 33a33f0ba4d7 16.0 landed