Re: appendBinaryStringInfo stuff - Mailing list pgsql-hackers

From Andres Freund
Subject Re: appendBinaryStringInfo stuff
Date
Msg-id 20221219081241.b3mxmwoendd4jzeq@alap3.anarazel.de
Whole thread Raw
In response to appendBinaryStringInfo stuff  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: appendBinaryStringInfo stuff  (David Rowley <dgrowleyml@gmail.com>)
Re: appendBinaryStringInfo stuff  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List 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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: (non) translatable string splicing
Next
From: Peter Eisentraut
Date:
Subject: Re: Common function for percent placeholder replacement