Re: contrib vs. gborg/pgfoundry for replication solutions
| От | Robert Treat |
|---|---|
| Тема | Re: contrib vs. gborg/pgfoundry for replication solutions |
| Дата | |
| Msg-id | 1082743368.25537.1123.camel@camel обсуждение исходный текст |
| Ответ на | Re: contrib vs. gborg/pgfoundry for replication solutions (Rod Taylor <pg@rbt.ca>) |
| Ответы |
Re: contrib vs. gborg/pgfoundry for replication solutions
Re: contrib vs. gborg/pgfoundry for replication solutions |
| Список | pgsql-hackers |
On Fri, 2004-04-23 at 11:02, Rod Taylor wrote:
> On Thu, 2004-04-22 at 23:05, Robert Treat wrote:
> > On Thursday 22 April 2004 13:55, Barry Lind wrote:
> > > I think the solution lies in improving www.postgresql.org. At the end
> > > of the day it doesn't matter where source code lives, what matters is
> > > can people find what they are expecting. Given we know what people are
> > > looking for, that should be front and center on the web site and the ftp
> > > sites.
>
> > But of course that solution always stalls out when it comes down to picking
> > which projects get the special treatment of direct links from the main
> > website and which ones stay out of the spotlight. With JDBC you might make
>
> I really don't see this as being any different than deciding which
> buffer strategy or website style to use. One is better in some way so it
> becomes a part of the system.
>
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.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
В списке pgsql-hackers по дате отправления: