Re: [proposal] protocol extension to support loadable stream filters

От: Brent Verner
Тема: Re: [proposal] protocol extension to support loadable stream filters
Дата: ,
Msg-id: 20050427003118.GA83182@rcfile.org
(см: обсуждение, исходный текст)
Ответ на: Re: [proposal] protocol extension to support loadable stream filters  (Tom Lane)
Ответы: Re: [proposal] protocol extension to support loadable stream filters  (Tom Lane)
Список: pgsql-hackers


[2005-04-25 18:34] Tom Lane said:
| Brent Verner <> writes:
| >   I'd like to introduce the concept of (dynamically loaded) stream
| > filters that would be used to wrap calls to send/recv by the FE/BE 
| > protocol.

| You certainly don't get to have any help
| from the database, for example, since you're not connected to it
| at the time of the connection startup.
Right.  The list of available filters would controlled at the
server level (in postgresql.conf).  A snippet of how I envision
configuring the filters...at the moment, anyway.  I suspect my
use of custom_variable_classes might be better done as a specific
enable_stream_filters option, but this is what I'm currently
working with...
 # # Define a custom_variable_class for each filter.  A filter, # $filterName, will be available iff $filterName.enable
==true # custom_variable_classes = 'ssl, zlib, ...'
 
 # see documentation of ssl filter for available options ssl.enable = true ssl.required = false
 # see documentation of zlib filter for available options zlib.enable = true zlib.required = true zlib.compression = 7


| I also wonder what happens when
| the client and server disagree on the meaning of a filter name.
 How this is any different than saying "...when the client and
server disagree on the meaning of a ProtocolVersion.", which is
how ssl support is currently requested/negotiated?  Either way,
client and server must agree on their behaviour.  This doesn't
change, AFAICS, when requesting support for some feature/filter
by name.  If the filter exists, an attempt will be made to
communicate through it, if that fails, the filter is not installed,
and the client ends up with a 'no support' response (or a disconnect
if the filter is required) and the client goes on without it.
 What am I overlooking?

| It
| would seem a lot safer to stick to the existing, low-tech, non dynamic
| approach.
 I still don't see what additional problems would be created by
using this StreamFilter API, so I'm going to march on and perhaps
the problems/difficulties will become apparent ;-)
 I could see the benefit in having some built-in StreamFilters, 
such as SSL (or zlib ;-)) that can't be replaced/overridden by 
dlopen'd code, but I think having the ability to provide alternate 
stream handling might be useful.


cheers.brent




В списке pgsql-hackers по дате сообщения:

От: Pavel Stehule
Дата:
Сообщение: Re: bitmapscan test, no success, bs is not faster
От: Simon Riggs
Дата:
Сообщение: Re: [PERFORM] Bad n_distinct estimation; hacks suggested?