On 2020/09/01 6:24, Tom Lane wrote:
> Per the discussion at [1], we're now aware of actual use-cases for
> password strings approaching a kilobyte in length. I think this puts
> the final nail in the coffin of the idea that passwordFromFile() can
> use a fixed-length line buffer. Therefore, commit 2eb3bc588 (which
> added a warning for overlength lines) seems rather misguided in
> hindsight. What we should do instead is fix that code so it has no
> hard upper bound on the line length.
AFAIR, there were proposals to increase the maximum length of password so far,
but we could not do that because we failed to get the consensus about
that change. But if we get the clear use-case requiring longer password and
reach the consensus, that's good news. I agree with the change.
> Even if you want to say that
> we'll set a particular limit on how long the password field can be,
> there's no good upper bound for the length of the hostname field;
> so ISTM that just getting out of the business of a fixed-size buffer
> is the sanest way.
>
> Hence, the attached proposed patch does that, and for good measure
> adds some testing of this formerly untested code.
>
> Since we now have an actual user complaint, I'm inclined to back-patch
> this all the way.
>
> As noted in the other thread, there may be some other changes needed
> to support long passwords, but this is clearly required.
Yes, some client tools have 100 bytes length restriction for the password.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
