From: Tom Lane <tgl@sss.pgh.pa.us>
To: Magnus Hagander <magnus@hagander.net>
cc: Euler Taveira <euler@timbira.com>, Florian Pflug <fgp@phlo.org>,
	Bruce Momjian <bruce@momjian.us>,
	Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: libpq compression
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>
Comments: In-reply-to Magnus Hagander <magnus@hagander.net>
	message dated "Sat, 16 Jun 2012 11:43:50 +0800"
Date: Sat, 16 Jun 2012 00:55:02 -0400
Message-ID: <11357.1339822502@sss.pgh.pa.us>

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