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

[2005-04-25 18:34] Tom Lane said:
| Brent Verner <brent(at)rcfile(dot)org> 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