[2005-04-25 18:34] Tom Lane said:
| Brent Verner <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
