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

2005-04-30 Thread Neil Conway
Alvaro Herrera wrote: BTW, why not get rid of src/corba? Good question; I'll remove it from HEAD tomorrow, barring any objections. -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

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

2005-04-29 Thread Alvaro Herrera
On Fri, Apr 29, 2005 at 10:17:44AM -0400, Tom Lane wrote: > Our experience with trying to write single files to serve both server > and client sides has been, um, painful. I recommend you not try this. BTW, why not get rid of src/corba? -- Alvaro Herrera (<[EMAIL PROTECTED]>) "XML!" Exclaimed

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

2005-04-29 Thread Tom Lane
Brent Verner <[EMAIL PROTECTED]> writes: > Now, the hard part...where should this code live? I'm thinking a > src/transport directory seems sensible. Our experience with trying to write single files to serve both server and client sides has been, um, painful. I recommend you not try this. My

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

2005-04-28 Thread Brent Verner
[2005-04-28 10:00] Tom Lane said: | Brent Verner <[EMAIL PROTECTED]> writes: | > Would it be sane to recognize a specific PG_PROTOCOL_MAJOR | > to enter the filter-negotiation process? PG_PROTOCOL_MINOR | > would then be used to lookup and call a ptr to the filter's | > create() in CreateStream

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

2005-04-28 Thread Tom Lane
Brent Verner <[EMAIL PROTECTED]> writes: > Would it be sane to recognize a specific PG_PROTOCOL_MAJOR > to enter the filter-negotiation process? PG_PROTOCOL_MINOR > would then be used to lookup and call a ptr to the filter's > create() in CreateStreamFilter... Looks reasonable enough to me ...

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

2005-04-27 Thread Brent Verner
[2005-04-26 23:00] Tom Lane said: | Brent Verner <[EMAIL PROTECTED]> writes: | > | 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 Pro

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

2005-04-26 Thread Tom Lane
Brent Verner <[EMAIL PROTECTED]> writes: > | 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

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

2005-04-26 Thread Brent Verner
[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,

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

2005-04-25 Thread Tom Lane
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. I think the "dynamically loaded" part of that is going to be way more headache than it's worth. You certa

[HACKERS] [proposal] protocol extension to support loadable stream filters

2005-04-25 Thread Brent Verner
Hackers, 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. The initial "StreamFilter" will be a zlib compression filter. Yeah, I know it could just be added along-side (in the same way as) the SSL cod