Re: appendBinaryStringInfo stuff
| От | Andres Freund |
|---|---|
| Тема | Re: appendBinaryStringInfo stuff |
| Дата | |
| Msg-id | 20221219081241.b3mxmwoendd4jzeq@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | appendBinaryStringInfo stuff (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
| Ответы |
Re: appendBinaryStringInfo stuff
Re: appendBinaryStringInfo stuff |
| Список | 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 по дате отправления: