On Wed, Feb 06, 2008 at 02:57:39AM -0500, Kris Jurka wrote: > > > On Tue, 5 Feb 2008, Tom Lane wrote: > > >The problem seems to be that AuthenticationGSSContinue messages carry > >a variable-length payload, and the V2 protocol doesn't really cope with > >that because it doesn't have a message length word. > > > >1. If the GSSContinue payload is self-identifying about its length, > >qwe could teach fe-connect.c how to determine that. > > The GSS data is supposed to be opaque to the caller, so this doesn't > seem likely or a good idea.
Yeah, agreed, that seems like a very fragile idea. > >2. We could retroactively redefine the contents of > >AuthenticationGSSContinue as carrying a length word after the > >authentication type code, but only in V2 protocol (so as not to break > >existing working cases). This is pretty ugly but certainly possible. > > I see no harm in doing this. What's there now can't work and the change > is self contained. Is there any problem with the password message taking > a "String" datatype instead of Byte[n] with a null byte? I agree that this is probabliy the best way, if we can do it. But you do raise a good point - the message that goes the other way can certainly contain embedded NULLs. //Magnus ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
