Re: Removing the fixed-size buffer restriction in hba.c

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Removing the fixed-size buffer restriction in hba.c
Дата
Msg-id ZL8T/jFmOjZ1Y0g7@paquier.xyz
обсуждение исходный текст
Ответ на Re: Removing the fixed-size buffer restriction in hba.c  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: Removing the fixed-size buffer restriction in hba.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Jul 24, 2023 at 03:58:31PM -0700, Nathan Bossart wrote:
> On Mon, Jul 24, 2023 at 03:07:07PM -0300, Fabrízio de Royes Mello wrote:
>>> Given the infrequency of complaints, I'm inclined to apply
>>> the more thorough fix only in HEAD, and to just raise MAX_TOKEN
>>> in the back branches.  Thoughts?
>>>
>>
>> It makes sense to change it only in HEAD.
>
> I wouldn't be opposed to back-patching the more thorough fix, but I don't
> feel too strongly about it.

- * The token, if any, is returned at *buf (a buffer of size bufsz), and
+ * The token, if any, is returned into *buf, and
  * *lineptr is advanced past the token.

The comment indentation is a bit off here.

  * In event of an error, log a message at ereport level elevel, and also
- * set *err_msg to a string describing the error.  Currently the only
- * possible error is token too long for buf.
+ * set *err_msg to a string describing the error.  Currently no error
+ * conditions are defined.

I find the choice to keep err_msg in next_token() a bit confusing in
next_field_expand().  If no errors are possible, why not just get rid
of it?

FWIW, I don't feel strongly about backpatching that either, so for the
back branches I'd choose to bump up the token size limit and call it a
day.
--
Michael

Вложения

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

Предыдущее
От: Vik Fearing
Дата:
Сообщение: Re: Row pattern recognition
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Removing the fixed-size buffer restriction in hba.c