Re: Should rolpassword be toastable?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Should rolpassword be toastable?
Date: 2024-10-03 21:39:06
Message-ID: 465160.1727991546@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> For the reasons discussed upthread [0], I can't bring myself to add an
> arbitrary limit to the password hash length. I am going to leave 0001
> uncommitted for now.
> [0] https://postgr.es/m/Zu2eT2H8OT3OXauc%40nathan

I'm confused, as in [0] you said

>> ... But on the off-chance
>> that someone is building a custom driver that generates long hashes for
>> whatever reason, I'd imagine that a clear error would be more helpful than
>> "row is too big."

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2024-10-03 21:52:33 Re: On disable_cost
Previous Message Nathan Bossart 2024-10-03 21:27:40 Re: Should rolpassword be toastable?