Tom Lane writes:
> > * Is it okay to ignore the count field in the password packet and read
> > the actual password like a null-terminated string? That was only there
> > for the postmaster way of handling incomplete packets, right?
>
> Seems like we ought to keep the packet-parsing rules the same, to avoid
> possible introduction of client compatibility problems.
Hmm, the current code cuts off the password at 99 (+/-1) characters. I
think there's a TODO item to get rid of those limits, and sending anything
else would be a (rather stupid) protocol violation anyway, so I think I
will keep this part.
> Um, shouldn't collection of the startup packet be done after the fork?
To handle query cancel requests we'd need to take a peek in the
postmaster, unless we want to start up a new backend for that. Also, I'm
not sure how the SSL negotiation would work. It's doable, might be
worthwhile, but should be a separate consideration.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
