Date: Thu, 19 Sep 2024 09:22:31 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Should rolpassword be toastable?
Message-ID: <Zuwzp09o9uiG0f0F@nathan>
References: <89e8649c-eb74-db25-7945-6d6b23992394@gmail.com>
 <1284094.1695479962@sss.pgh.pa.us>
 <67793ae1-3adc-a6e0-0bb3-c23a28c0627a@gmail.com>
 <a9524f94-316c-349a-6e4d-79b878706f82@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a9524f94-316c-349a-6e4d-79b878706f82@gmail.com>
Archived-At: <https://www.postgresql.org/message-id/Zuwzp09o9uiG0f0F%40nathan>
Precedence: bulk

On Thu, Sep 19, 2024 at 06:00:00AM +0300, Alexander Lakhin wrote:
> 23.09.2023 21:00, Alexander Lakhin wrote:
>> So for now only pg_authid is worthy of condemnation, AFAICS.
> 
> Let me remind you of this issue in light of b52c4fc3c.
> Yes, it's opposite, but maybe it makes sense to fix it now in the hope that
> ~1 year of testing will bring something helpful for both changes.

Hm.  It does seem like there's little point in giving pg_authid a TOAST
table, as rolpassword is the only varlena column, and it obviously has
problems.  But wouldn't removing it just trade one unhelpful internal error
when trying to log in for another when trying to add a really long password
hash (which hopefully nobody is really trying to do in practice)?  I wonder
if we could make this a little more user-friendly.

-- 
nathan