From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: "Jonathan S. Katz" <jkatz@postgresql.org>,
        Michael Paquier <michael@paquier.xyz>,
        Alexander Lakhin <exclusion@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Should rolpassword be toastable?
In-reply-to: <Zv8MTMy87pRlRqD_@nathan>
References: <ZuxjAIOJ4GSa34KC@nathan> <ZuydAj4nrt4cpGU5@nathan> <2047353.1726784074@sss.pgh.pa.us> <0a9b7f96-aa2f-41eb-8e69-62f7990ebf74@postgresql.org> <Zuzh6Nq750L9BZn5@nathan> <Zu0G7s-k8iECVG7i@paquier.xyz> <0d8f3541-13f4-4194-8dca-bae881cf1a9a@postgresql.org> <Zu2eT2H8OT3OXauc@nathan> <2445149.1726849661@sss.pgh.pa.us> <Zu8r0oO0Vi0FxdpB@nathan> <Zv8MTMy87pRlRqD_@nathan>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Thu, 03 Oct 2024 16:27:40 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <465159.1727991546.1@sss.pgh.pa.us>
Date: Thu, 03 Oct 2024 17:39:06 -0400
Message-ID: <465160.1727991546@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/465160.1727991546%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.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