Re: contrib vs. gborg/pgfoundry for replication solutions

Rod Taylor <pg(at)rbt(dot)ca> writes:

>> The difference is that a "better" admin tool is very subjective where as
>> a buffer strategy is not... or maybe the difference is really that
>> everyone thinks they are qualified to pick a "better" admin tool, but
>> very few can really argue as to a better buffer strategy. While I think
>> your criteria is pretty close to what I would use, I still couldn't pick
>> which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql...
>> and even I did I bet some people would have a problem with my choices.
>
> If you have a hard time picking between those projects, imagine the
> difficulties someone who has never used PostgreSQL has just tracking
> down the options available to them.

Exactly. MySQL makes no bones about choosing "blessed" projects. I
don't think that MySQL AB's MySQL Control Center is the best MySQL
GUI, but it's better than the "default" PostgreSQL choice. MySQL
shoves a workable solution under the end user's nose. PostgreSQL
gives the potential user a wide array of choices, none of which are
particularly easy to find. How many GUI tools are listed on GBorg?
How many potential users even know to look at GBorg at all?

One thing is certain most users aren't going to find psql (probably
compiled without readline support) comparable with MySQL Control
Center. Not to mention the fact that not having a set of "blessed"
tools means that we end up with competing tools. PostgreSQL has
several replication toolsets, piles of admin tools, and several
competing language bindings for some of the most popular development
languages.

How many Python bindings does PostgreSQL need?

PostgreSQL has some amazing supporting tools, but they are all hidden
in an unlighted basement in a locked filing cabinet next to a sign
that reads "Beware of the Leopard."

> We would not be removing any choices for the user. We're simply
> supplying a list of suggested tools that they may have interest in.

Exactly. Yes, choosing tools requires some politics, and it will
inevitably make some users and developers upset because their projects
will get passed over for more popular ones. However, this will
certainly help new users that are looking at PostgreSQL for the first
time. They will be able to see, right off, what *sort* of tools are
available for use with PostgreSQL. Later on as these people become
part of the PostgreSQL community they might even find out about
alternative tools that they like better.

> Getting the user to download PostgreSQL and give it a shot without
> becoming frustrated because the "basics" were not available (in an
> obvious location) is the first step.

PostgreSQL stacks up well as a database. In fact, it rocks. But
comparing plain Jane PostgreSQL against other databases and their
assorted suite of tools is not going to work in PostgreSQL's favor.
Fortunately PostgreSQL has comparable supporting tools as well.
Unfortunately no one knows about these tools except for those of us on
the PostgreSQL lists.

> Step 2 is to inform the user that there are more alternatives available.
> I see pgFoundary doing a good job of #2 -- but it is not going to help
> with #1 (too much choice is as bad as none at all to a beginner).

Precisely. The trick is to promote PostgreSQL and a core set of
tools. These tools don't have to be part of PostgreSQL's CVS (or even
be available for download) from the postgresql.com site, but they
should receive "top" billing. When the end user looks for a GUI,
there should be a single solitary GUI that should be the "default"
choice. When the end user asks about replication they should be
guided to a single solution. In cases where it is difficult to decide
what the default case might be--like in the case of replication where
the tools you will want to use depends on what you are trying to
accomplish--simply point users at the most common scenario and then
document that they might need to use other tools to solve different
problems.

Jason