On Thu, Oct 03, 2024 at 05:39:06PM -0400, Tom Lane wrote: > I agree with the idea that complaining about the password being too > long is far more intelligible than that. Another problem with > leaving it as it stands in HEAD is that the effective limit is now > platform-specific, if not indeed dependent on the phase of the moon > (or at least, the other contents of the pg_authid row). I fear it > would be very easy to construct cases where a password is accepted > on one machine but fails with "row is too big" on another. A > uniform limit seems much less fraught with surprises.
I don't mind proceeding with the patch if there is strong support for it. I wavered only because it's hard to be confident that we are choosing the right limit. AFAICT 256 bytes ought to be sufficient to avoid "row is too big" errors independent of BLCKSZ today, but maybe someone will add another varlena column in the future that breaks it. Or maybe we add a new password hashing method that produces longer strings. Or maybe someone is doing something really out there like storing additional information in the salt. I don't have any reason to believe that any of these things are happening or are likely to happen anytime soon, but they seem similar in likelihood to someone building a custom driver that generates ginormous hashes. But I can also buy the argument that none of this is a strong enough reason to avoid making the error message nicer... -- nathan
