Re: rmgr hooks (v2)

Simon Riggs  writes:

> On Wed, 2009-01-21 at 14:28 +0000, Greg Stark wrote:
>
>> The only advantage that remains, I think, is the real-world concern
>> that you can have proprietary plugins 
>
> ** I have no plans for selling software that has been enabled by this
> patch. **

Hm, I didn't specifically mean this. However I'm not sure why this would be
considered so prejudicial. The Postgres project isn't generally hostile to
commercial use and extensions. If there was something you *did* want to sell
based on this and you needed a clean, generally useful interface to do it then
I think it would be an argument in *favour* of providing it, not against.

But I meant more generally, that the real-world use case for a generic rmgr
plugin function is for providing interfaces for things which cannot -- for
whatever non-code-related reason -- be integrated in core. That is, from a
code point of view they would be best integrated in core. So either they're
not generally useful, not production quality, not license compatible, or
whatever.

> The plugin approach was suggested because it brings together so many use
> cases in one and adds missing robustness to a case where we already have
> extensibility. Extensibility is about doing things for specific
> implementations *without* needing to patch Postgres, not just allowing
> external projects to exist alongside.

I think a generic plugin architecture is *too* many use cases. That is it's
too flexible and doesn't make any promises at all of what its intended to do.
As a result the system can't be sure it's calling the right method, can't
detect conflicts or catch errors. There's a sweet spot of abstraction where
the interface has to be specific enough to be useful but general enough to
cover all the use cases.

I'm not sure though, your comments in the other email make me think there
might be more to the patch that I had the impression was there. Will now go
read the patch and see if I was mistaken.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!