Re: appendBinaryStringInfo stuff

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: appendBinaryStringInfo stuff
Дата
Msg-id ca599ac2-7025-0984-52a7-6a4f3894016b@dunslane.net
обсуждение исходный текст
Ответ на Re: appendBinaryStringInfo stuff  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: appendBinaryStringInfo stuff  (David Rowley <dgrowleyml@gmail.com>)
Re: appendBinaryStringInfo stuff  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2022-12-19 Mo 17:48, David Rowley wrote:
> On Tue, 20 Dec 2022 at 11:42, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think Peter is entirely right to question whether *this* type's
>> output function is performance-critical.  Who's got large tables with
>> jsonpath columns?  It seems to me the type would mostly only exist
>> as constants within queries.
> The patch touches code in the path of jsonb's output function too. I
> don't think you could claim the same for that.
>

I agree that some of the uses in the jsonpath code could reasonably just
be converted to use appendStringInfoString()

There are 5 uses in the jsonb code where the length param is a compile
time constant:

andrew@ub22:adt $ grep appendBinary.*[0-9] jsonb*
jsonb.c:            appendBinaryStringInfo(out, "null", 4);
jsonb.c:                appendBinaryStringInfo(out, "true", 4);
jsonb.c:                appendBinaryStringInfo(out, "false", 5);
jsonb.c:                appendBinaryStringInfo(out, ": ", 2);
jsonb.c:            appendBinaryStringInfo(out, "    ", 4);

None of these really bother me much, TBH. In fact the last one is
arguably nicer because it tells you without counting how many spaces
there are.

Changing the type of the second argument to appendBinaryStringInfo to
void* seems reasonable.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: Add LZ4 compression in pg_dump
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Use get_call_result_type() more widely