From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: appendBinaryStringInfo stuff |
Date: | 2022-12-19 08:12:41 |
Message-ID: | 20221219081241.b3mxmwoendd4jzeq@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-12-19 08:13:09 | Re: Common function for percent placeholder replacement |
Previous Message | Alvaro Herrera | 2022-12-19 08:07:57 | Re: (non) translatable string splicing |