Re: libpq compression

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: libpq compression
Дата
Msg-id 20180605070928.GA4973@paquier.xyz
обсуждение исходный текст
Ответ на Re: libpq compression  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: libpq compression  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Re: libpq compression  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
On Tue, Jun 05, 2018 at 06:04:21PM +1200, Thomas Munro wrote:
> On Thu, May 17, 2018 at 3:54 AM, Konstantin Knizhnik
> Speaking of configuration, are you planning to support multiple
> compression libraries at the same time?  It looks like the current
> patch implicitly requires client and server to use the same configure
> option, without any attempt to detect or negotiate.  Do I guess
> correctly that a library mismatch would produce an incomprehensible
> corrupt stream message?

I just had a quick look at this patch, lured by the smell of your latest
messages...  And it seems to me that this patch needs a heavy amount of
work as presented.  There are a couple of things which are not really
nice, like forcing the presentation of the compression option in the
startup packet to begin with.  The high-jacking around secure_read() is
not nice either as it is aimed at being a rather high-level API on top
of the method used with the backend.  On top of adding some
documentation, I think that you could get some inspiration from the
recent GSSAPI encription patch which has been submitted again for v12
cycle, which has spent a large amount of time designing its set of
options.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: commitfest 2018-07
Следующее
От: David Rowley
Дата:
Сообщение: Re: Spilling hashed SetOps and aggregates to disk