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@sss.pgh.pa.us> wrote:
>>
>> Nathan Bossart <nathandbossart@gmail.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