From: Tom Lane <tgl@sss.pgh.pa.us>
To: Magnus Hagander <magnus@hagander.net>
Cc: Euler Taveira <euler@timbira.com>
Cc: Florian Pflug <fgp@phlo.org>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: libpq compression
Date: Sat, 16 Jun 2012 00:55:02 -0400
Message-ID: <11357.1339822502@sss.pgh.pa.us> (raw)
In-Reply-To: <CABUevEz_V4YYc0tUhkC6KD2GddysM5Z76pcHcMYiMDd7dwMxVQ@mail.gmail.com>
References: <4FD9698F.2090407@timbira.com>
<29853.1339651170@sss.pgh.pa.us>
<4FD9E70B.9040607@timbira.com>
<11502.1339699384@sss.pgh.pa.us>
<20120615021938.GA21704@momjian.us>
<CABUevEyv4T+1gR6_Uqm_1qUD9PNDg6UdXbJhwHZgFi9hpQQ6NQ@mail.gmail.com>
<F3B8BAA6-23E9-423A-A7D1-D2E14769F326@phlo.org>
<CABUevExi-cJ6AvF2kDOy+qQsB+0JHofrcvVmNVoJ2HziZMMaAg@mail.gmail.com>
<22690C61-E960-4A2A-BFD5-DAD3D3B5C474@phlo.org>
<CABUevEzVpqS5RCLz2fFREdPFkuYkEKsrMpnfPixYWPki2=iJOA@mail.gmail.com>
<4FDB954F.9010606@timbira.com>
<5136.1339799120@sss.pgh.pa.us>
<5365.1339799869@sss.pgh.pa.us>
<CABUevEz_V4YYc0tUhkC6KD2GddysM5Z76pcHcMYiMDd7dwMxVQ@mail.gmail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, magnus@hagander.net, euler@timbira.com, fgp@phlo.org, bruce@momjian.us
Subject: Re: libpq compression
In-Reply-To: <11357.1339822502@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox