Re: [DOCS] Replication documentation addition

Hi,

I also wrote Bruce about that.

It happens that, if you 'freely advertise' commercial solutions (rather 
than they doing so by other vehicles) you will always happen to be an 
'updater' to the docs if they change their product lines, if they change 
their business model, if and if.

If you cite a commercial solution, as a fair game you should cite *all* 
of them. If one enterprise has the right to be listed in the 
documentation, all of them might, as you will never be favouring one of 
them.

That's the main motivation to write this. Moreover, if there are also 
commercial solutions for high-end installs and they are cited as 
providers to those solutions, it (to a point) disencourages those of 
gathering themselves and writing open source extensions to PostgreSQL.

As Bruce stated, then should the documentation contemplate 
EnterpriseDB's Oracle functions? Should PostgreSQL also come with it? 
Wouldn't it be painful to make, say, another description for an 
alternate product other than EnterpriseDB if it arises?

If people (who read the documentation) professionally work with 
PostgreSQL, they may already have been briefed by those commercial 
offerings in some way.

I think only the source and its tightly coupled (read: can compile along 
with, free as PostgreSQL) components should be packaged into the tarball.

However, I find Bruce's unofficial wiki idea a good one for comparisons.

Regards,
Cesar

Steve Atkins wrote:
>
> On Oct 24, 2006, at 9:20 PM, Bruce Momjian wrote:
>
>> Steve Atkins wrote:
>>>> If we are to add them, I need to hear that from people who haven't
>>>> worked in PostgreSQL commerical replication companies.
>>>
>>> I'm not coming to PostgreSQL for open source solutions. I'm coming
>>> to PostgreSQL for _good_ solutions.
>>>
>>> I want to see what solutions might be available for a problem I have.
>>> I certainly want to know whether they're freely available, commercial
>>> or some flavour of open source, but I'd like to know about all of them.
>>>
>>> A big part of the value of Postgresql is the applications and 
>>> extensions
>>> that support it. Hiding the existence of some subset of those just
>>> because of the way they're licensed is both underselling postgresql
>>> and doing something of a disservice to the user of the document.
>>
>> OK, does that mean we mention EnterpriseDB in the section about Oracle
>> functions?  Why not mention MS SQL if they have a better solution?  I
>> just don't see where that line can clearly be drawn on what to include.
>> Do we mention Netiza, which is loosely based on PostgreSQL?   It just
>> seems very arbitrary to include commercial software.  If someone wants
>> to put in on a wiki, I think that would be fine because that doesn't
>> seems as official.
>
> Good question. The line needs to be drawn somewhere. It's basically
> your judgement, tempered by other peoples feedback, though. If it
> were me, I'd ask myself "Would I mention this product if it were open
> source? Would mentioning it help people using the document?".
>
> Cheers,
>   Steve
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>               http://archives.postgresql.org
>