> I'm not that clueful about SASL -- would this mean that we could get
> rid of the PostgreSQL code that does SSL connections, plus MD5, crypt,
> ident, etc. based authentication, and instead just use the SASL stuff?
We would still need the ability to map user identities -> pgusers for
those methods where the client can't specify an arbitrary user name
(e.g., Kerberos and GSSAPI), but strictly speaking that's an "authorization"
problem, not an "authentication" problem, and it can be handled entirely
within the backend.
> [W]ould SSL/TLS support need to co-exist with SASL?
Yes. SASL effectively works at the application layer. It's now common
practice for one of the application commands to be STARTTLS (perhaps by
another name) that both sides use as a signal to negotiate a TLS/SSL
session.
The benefit of this approach is that it's easily migrated to Unix
sockets, IPv6, etc.
> > 2) add ZLIB compression.
>
> This was discussed before, and the conclusion was that compression
> is of fairly limited utility, and can be accomplished by using
> ssh -- so it's not worth the bloat. But there were some dissenting
> opinions at the time, so this might merit further discussion...
I agree, it wasn't worth the effort with the existing code. But
if we rewrite the lowest level routines then the amount of bloat can
be minimized.
Bear