From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Removing the fixed-size buffer restriction in hba.c |
Date: | 2023-07-25 00:14:54 |
Message-ID: | ZL8T/jFmOjZ1Y0g7@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-07-25 00:21:54 | Re: Removing the fixed-size buffer restriction in hba.c |
Previous Message | Vik Fearing | 2023-07-24 23:14:37 | Re: Row pattern recognition |