Greetings,
* Bossart, Nathan (bossartn@amazon.com) wrote:
> On 10/12/18, 3:52 PM, "Stephen Frost" <sfrost@snowman.net> wrote:
> > If we're going to do work in this area, why wouldn't we have the client
> > tools and the server agree on the max length and then have them all be
> > consistent..?
> >
> > Seems odd to decide that 100 character buffer size in the clients makes
> > sense and then make the server support an 8k password.
>
> I considered this but wondered if expanding the buffers over 80x was
> too intrusive or if the 100 character limit had some historical
> purpose. I'm happy to align everything if desired.
The way to sort that out would likely to be go look at the history...
That said, assuming we do adjust the limit to be higher, it'd probably
make more sense to allocate it and not just have it on the stack (which
might be why it's the size it is today...).
> > I'm also trying to figure out why it makes sense to support an 8k
> > password and if we've really tried seeing what happens if pg_authid gets
> > a toast table that's actually used for passwords...
>
> Since v10+ always stores passwords encrypted [0], I don't think it
> will require a TOAST table.
Yeah, that was pointed out downthread, I'd forgotten that we (finally)
got rid of storing plaintext passwords; sometimes it's difficult to
believe that we've actually moved forward with something that some of us
complained about many, many, many years ago. ;)
> > I'll note your patches neglected to include any tests...
>
> I will look into adding tests. I've also been told that there may be
> some limits for the .pgpass file, so I am looking into that as well.
Ok.
Thanks!
Stephen