Magnus Hagander <magnus@hagander.net> writes:
> Yes, but there's also a lot of such awkward logic we need to add if we
> *do* go with the SSL library doing the compression:
> For example, we can no longer trust the SSL library to always do
> encryption, since we specifically want to support null encryption.
True, but are you sure we don't need to do that anyway? What happens
today, if a non-libpq client connects with SSL and specifies null
encryption?
> And we currently have no way to specify different
> encryption options on a per-host basis, which is something we'd have
> to do (e.g. i want to be able to say that "subnet x requires
> encryption with these encryptions methods" and "subnet y doesn't
> require encryption but should do compression".
[ shrug... ] Having that sort of control over a homebrew compression
solution will *also* require a lot of control logic that does not exist
today.
> So there's quite a bit of complexity that needs to be put in there
> just to deal with the fact that we're using SSL to do compression, if
> we want to support it in a way that's not hackish.
It's not obvious to me that we actually *need* anything except the
ability to recognize that a null-encrypted SSL connection probably
shouldn't be treated as matching a hostssl line; which is not something
that requires any fundamental rearrangements, since it only requires an
after-the-fact check of what was selected. Things like "subnet x
requires encryption with these encryption methods" are features that are
sensible with our existing feature set. But we don't have that now and
nobody has asked for it, so I think you are moving the goalposts rather
unfairly by claiming that a compression-related patch needs to add it.
regards, tom lane