From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Jonathan S. Katz" <jkatz@postgresql.org>
cc: Jacob Champion <jacob.champion@enterprisedb.com>,
        Nathan Bossart <nathandbossart@gmail.com>,
        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: <aefad126-df60-483b-b1c5-ef3c305f5923@postgresql.org>
References: <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> <465160.1727991546@sss.pgh.pa.us> <Zv8X3YVzuPfh1Fht@nathan> <473657.1727994294@sss.pgh.pa.us> <CAOYmi+mVJDy+ja1Un3PSZHq2G4PYq1A-ROfR-rSoOtN-PVK4XA@mail.gmail.com> <aefad126-df60-483b-b1c5-ef3c305f5923@postgresql.org>
Comments: In-reply-to "Jonathan S. Katz" <jkatz@postgresql.org>
	message dated "Thu, 03 Oct 2024 22:17:31 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <510906.1728009184.1@sss.pgh.pa.us>
Date: Thu, 03 Oct 2024 22:33:04 -0400
Message-ID: <510907.1728009184@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/510907.1728009184%40sss.pgh.pa.us>
Precedence: bulk

"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> I think Tom's initial suggestion (BLCKSZ/2) is better than 256, given we 
> really don't know what' out there in the wild, and this could end up 
> being a breaking change. Every other type in pg_authid is pretty small. 

I'm having second thoughts about that though, based on the argument
that we don't really want a platform-dependent limit here.
Admittedly, nobody changes BLCKSZ on production systems, but it's
still theoretically an issue.  I don't have a problem with selecting
a larger limit such as 512 or 1024 though.

> That said, I'm also imagining other things we may add that could require 
> TOAST support (remembering previous passwords? storing multiple 
> passwords options)?

Things like previous passwords probably don't need to be accessed
during authentication, so there are at least a couple of ways we
could do that:
* put the previous passwords in an auxiliary table;
* put back pg_authid's toast table, but mark rolpassword as
"STORAGE MAIN" so it doesn't go to toast, while letting columns
that don't need to be touched at startup go there.

However, if you wanted to allow multiple passwords I'm not
sure about a good way.

			regards, tom lane