Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode
Дата
Msg-id CAEudQAp0A7vqSWB+cqOexDNXBUVvconDJTuj68v8cY6faKXesw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Em ter., 17 de ago. de 2021 às 00:43, Michael Paquier <michael@paquier.xyz> escreveu:
On Mon, Aug 16, 2021 at 02:06:31PM -0300, Ranier Vilela wrote:
> uint64 and size_t in 64 bits are equivalents.
> uint64 and size_t in 32 bits can be weird, but anyway size_t at 32 bits can
> handle 1GB.

There is usually a reason why things are done as they are, so before
suggesting changing something I would advise to read the threads that
created those changes more carefully because they could be mentioned.
In this case, we are talking about aef8948, and this part of its
related thread:
https://www.postgresql.org/message-id/20210105034739.GG7432@momjian.us
Because things have always been done a certain way doesn't mean it's right.
Using int to address strings is an mistake.
Even with an artificial limitation to only deal with 1GB, the correct one to use would be size_t.



> base64.c can be made in another patch.

This file is a set of code paths used by authentication and SCRAM, it
will never get as hot as the code paths that Hans has reported as
these are one-time operations.  Please note as well cfc40d3 for the
reasons why things are handled this way.  We absolutely have to use
safe routines here.
I have no plans to touch base64.c

regards,
Ranier Vilela

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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Allow parallel DISTINCT
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o