Horton

Re: Should rolpassword be toastable?

Jonathan S. Katz <jkatz@postgresql.org>

View thread View on postgr.es
From: "Jonathan S. Katz" <jkatz@postgresql.org>
To: Michael Paquier <michael@paquier.xyz>, Nathan Bossart <nathandbossart@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-09-20T14:06:28Z
Lists: pgsql-hackers 
On 9/20/24 1:23 AM, Michael Paquier wrote:
> On Thu, Sep 19, 2024 at 09:46:00PM -0500, Nathan Bossart wrote:
>> On Thu, Sep 19, 2024 at 07:37:55PM -0400, Jonathan S. Katz wrote:
>>>> Shouldn't we enforce the limit in every case in encrypt_password,
>>>> not just this one?  (I do agree that encrypt_password is an okay
>>>> place to enforce it.)
>>
>> Yeah, that seems like a good idea.  I've attached a more fleshed-out patch
>> set that applies the limit in all cases.
> 
> Not sure.  Is this really something we absolutely need?  Sure, this
> generates a better error when inserting a record too long to
> pg_authid, but removing the toast relation is enough to avoid the
> problems one would see when authenticating.  Not sure if this argument
> is enough to count as an objection, just sharing some doubts :)

The errors from lack of TOAST are confusing to users. Why can't we have 
a user friendly error here?

Jonathan

Commits

  1. Restrict password hash length.

  2. Remove pg_authid's TOAST table.

  3. Remove arbitrary restrictions on password length.