Subject: Re: libpq compression
To: Andres Freund <andres@anarazel.de>
Cc: "Iwata, Aya" <iwata.aya@jp.fujitsu.com>,
 Michael Paquier <michael@paquier.xyz>,
 Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
 Robert Haas <robertmhaas@gmail.com>,
 "rharwood@redhat.com" <rharwood@redhat.com>,
 Thomas Munro <thomas.munro@enterprisedb.com>,
 "g.smolkin@postgrespro.ru" <g.smolkin@postgrespro.ru>,
 PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>,
 'Dmitry Dolgov' <9erthalion6@gmail.com>
References: 
 <CA+Tgmob08ikN03bZGgrf=nUAYkZ2-ZuRuWqP-BBkUq9v_AEw=Q@mail.gmail.com>
 <8d9386be-a567-c526-2fc1-153d6ffd3507@2ndQuadrant.com>
 <17747c8b-c088-6f92-38e9-98316910202a@postgrespro.ru>
 <20181001064903.GG11712@paquier.xyz>
 <c79ff1a0-d2c7-c513-598e-f9658329654b@postgrespro.ru>
 <CA+q6zcVaT=m-Py-R2ap0oZDEWxUkKR9hFqDpVNNtHTGTkbd75g@mail.gmail.com>
 <71E660EB361DF14299875B198D4CE5423DEB752E@g01jpexmbkw25>
 <1b2d418b-f3b1-620e-8456-145d6e943da6@postgrespro.ru>
 <71E660EB361DF14299875B198D4CE5423DED67E5@g01jpexmbkw25>
 <dae47f7a-9e33-8cba-859c-dbd39bebe218@postgrespro.ru>
 <20190208185703.xy35plk7mb4ve57d@alap3.anarazel.de>
From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Message-ID: <512b537f-ca42-1f61-4f87-d7197949c455@postgrespro.ru>
Date: Sat, 9 Feb 2019 01:10:45 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <20190208185703.xy35plk7mb4ve57d@alap3.anarazel.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk


On 08.02.2019 21:57, Andres Freund wrote:
> On 2019-02-08 12:15:58 +0300, Konstantin Knizhnik wrote:
>> Frankly speaking, I do not think that such flexibility in choosing
>> compression algorithms is really needed.
>> I do not expect that there will be many situations where old client has to
>> communicate with new server or visa versa.
>> In most cases both client and server belongs to the same postgres
>> distributive and so implements the same compression algorithm.
>> As far as we are compressing only temporary data (traffic), the problem of
>> providing backward compatibility seems to be not so important.
> I think we should outright reject any patch without compression type
> negotiation.
Does it mean that it is necessary to support multiple compression 
algorithms and make it possible to perform switch between them at 
runtime? Right now compression algorithm is linked statically. 
Negotiation of compression type is currently performed but it only 
checks that server and client are implementing the same algorithm and 
disables compression if it is not true.

If we are going to support multiple compression algorithms, do we need 
dynamic loading of correspondent compression libraries or static linking 
is ok? In case of dynamic linking we need to somehow specify information 
about available compression algorithms.
Some special subdirectory for them so that I can traverse this directory 
and try to load correspondent libraries?

Only I find it too complicated for the addressed problem?