Magnus Hagander <mag...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers