Re: Should rolpassword be toastable?

On 10/3/24 7:29 PM, Jacob Champion wrote:
> On Thu, Oct 3, 2024 at 3:25 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
>>> I don't mind proceeding with the patch if there is strong support for it.
>>> I wavered only because it's hard to be confident that we are choosing the
>>> right limit.
>>
>> I'm not that fussed about it; surely 256 is more than anyone is using?
>> If not, we'll get push-back and then we can have a discussion about the
>> correct limit that's informed by more than guesswork.
>
> +1.
>
> Next up is probably SCRAM-SHA-512, which should still have smaller
> entries than that -- 222 bytes, I think, with 128-bit salts and a
> 5-digit iteration count?

The challenge is that salts can be an arbitrary length, even today (as
can the iterator value, though IIRC I think we check if it's in int
bounds, and a large iterator becomes pretty impractical for usage).

Probabalistically, it's unlikely there are many very large salts in the
wild (though I don't have data on that) and most folks are using the
default length, but that probability isn't 0.

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.
That said, I'm also imagining other things we may add that could require
TOAST support (remembering previous passwords? storing multiple
passwords options)?

Thanks,

Jonathan