[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] [proposal] protocol extension to support loadable stream filters
From:       Brent Verner <brent () rcfile ! org>
Date:       2005-04-27 0:31:18
Message-ID: 20050427003118.GA83182 () rcfile ! org
[Download RAW message or body]

[2005-04-25 18:34] Tom Lane said:
| Brent Verner <brent@rcfile.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


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
[prev in list] [next in list] [prev in thread] [next in thread]