From: | Brent Verner <brent(at)rcfile(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [proposal] protocol extension to support loadable stream filters |
Date: | 2005-04-27 00:31:18 |
Message-ID: | 20050427003118.GA83182@rcfile.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
[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
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2005-04-27 01:49:22 | Disable large objects GUC |
Previous Message | Rod Taylor | 2005-04-27 00:16:32 | Re: [PERFORM] Bad n_distinct estimation; hacks suggested? |