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  (David Rowley <dgrowleyml@gmail.com>)
Re: appendBinaryStringInfo stuff  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: (non) translatable string splicing
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Common function for percent placeholder replacement