Marko Kreen wrote:
> 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?

Anything that might cause one implementation to differ from another.
(e.g. - where Skytools and Slony-I might have differing code)

I have no particular inconsistency in mind; I don't expect any.

I don't think there's any *good* reason for them to differ; I'd hope
they wouldn't differ.  They can't, otherwise the separate versions
would need to be retained.

>> -> 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.

I can think of a third possibility, actually...  If it's not to be
"core," it might be a good idea to use the "pgxs" facility for it.

I was thinking of looking at changing Slony-I to use PGXS,
unfortunately it's effort that I just don't have time for at the
moment.  That would seem a slick idea for 2.1 or so...
-- 
output = ("cbbrowne" "@" "linuxdatabases.info")
http://linuxdatabases.info/info/nonrdbms.html
"The only ``intuitive'' interface is the nipple. After that, it's all
learned."  -- Bruce Ediger, bediger at teal.csn.org on X interfaces.