On 9/21/07, Christopher Browne <cbbrowne at ca.afilias.info> wrote:
> "Marko Kreen" <markokr at gmail.com> writes:
> > Only question is - Are Slony-I devs interested in common module?
> > And do they want some changes in it?
>
> This seems generally like a good idea, in much the same way that it
> was a really nice thing to get the trigger changes into PostgreSQL
> 8.3, as that will end the need for "catalogue mangling" in PostgreSQL.

Good!

> I'd rather see it in "core" than in "contrib," as that increases the
> probability (to unity :-)) that it'll be included, by default, in
> PostgreSQL distributions.

I just thought that maybe proposing to contrib first makes it
more edible to Postgres -core (also easier to me).  If the
interface is stable and agreed on, we can move it to core.

It may even happen in 8.4 timeframe, just that doing the first
proposal to /contrib seems more safe.

> The only thing that might (or mightn't!) be controversial is that it's
> pretty vital that the implementation remains consistent.

What inconsistencies are you thinking of?

> -> Having it in "core" pushes the probability of that towards unity
>
> -> Ditto for "contrib"
>
> -> If it's an external third party thing, then it seems to me that it
>    makes sense for projects that need it to consciously grab the code
>    and include it, so that they're not adding a little nagging
>    extra 3rd party external module that users will have to manage.
>
>    (That's one of the problems with CPAN, in the Perl world; I tried
>    adding a CPAN module last night, only to discover it referenced
>    something like half a dozen weirdly interlinking other CPAN
>    modules.)

Yes, the copying around is silly.  Also, the module may be small
and straightforward, but the usage can be tricky, as you should
know well ;)  It's would be good if all the usage documentation
and examples are in one place.  otherwise anyone using the module
will need to re-invent same things.

-- 
marko