Euler Taveira <eu...@timbira.com> writes: > I see the point in not adding another dependencies or reinventing the wheel > but I see more drawbacks than benefits in adopting a SSL-based compression.
In the end, judging this tradeoff is a matter of opinion, but I come to the opposite conclusion. Transport-level compression is not part of the core competence of this project. As such, if we have an opportunity to farm out that work to other projects (particularly ones that we are already relying on), we should do so. Not expend our limited resources on re-inventing this wheel, which we'd be more likely than not to do so less well than it's already been done. To draw an analogy: on the basis of the arguments that have been made about how some users might not have access to an SSL library implementing feature X, we should drop our use of OpenSSL entirely and re-implement transport encryption from scratch, incompatibly with OpenSSL. Now that's obviously ridiculous, not least because it does nothing at all to ease the pain of people who need a non-C implementation. But arguing that we should not use OpenSSL's compression features because some people might need to use a different SSL implementation doesn't seem to me to be any different from that. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers