> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > We aren't. I can do that, but have not discussed it yet. If we do it
> > is clearly a protocol change. How will old clients handle longer salt,
> > and how do I know if they are older if I don't bump up the protocol
> > version number?
>
> All of this is under the aegis of a new auth method code, so it doesn't
> matter. Either clients handle the new auth method, or they don't.
OK, I see how I can do that. I thought the salt was part of the startup
packet but I see now that it is send during the authentication request.
I can make it longer, probably 6 characters:
> 62^6
56800235584
I can get that out of an int4. I will take a single rand() and break it
into bsd62 pieces.
> The problem with bumping the protocol version number is that it breaks
> client-to-server compatibility *whether or not a particular connection
> needs the new auth method*. Eg, a new client will be unable to talk to
> an old server. This is not good.
Why is this the case? There is nothing in the new client code that will
conflict with an old server, right? Is it something hardwired in the
client code?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
