Magnus Hagander <> 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

> 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

> 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

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to