Re: why postgresql over other RDBMS
От | Alexander Staubo |
---|---|
Тема | Re: why postgresql over other RDBMS |
Дата | |
Msg-id | 88daf38c0705240830s4297181el40f5a22984d6f2f9@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: why postgresql over other RDBMS (Richard Huxton <dev@archonet.com>) |
Ответы |
Re: why postgresql over other RDBMS
Re: why postgresql over other RDBMS |
Список | pgsql-general |
On 5/24/07, Richard Huxton <dev@archonet.com> wrote: > Tom Allison wrote: > > You've addressed cost and performance. > > Not much left. > > > > Try it out for yourself and see if it works for you. > > + elephant in logo > - unpronounceable name > + excellent mailing lists > + excellent developer community > - you can download as many copies as you like and a salesman still won't > take you out to lunch + Friendly toolset in the box. [1] + Transactional DDL. [2] + Table inheritance, if you care to use unportable features. + Extensibility. [3] + PostGIS for spatial extensions. - Replication offerings suck. - Warm standby involve a lot of manual labour. - Point-in-time recovery involve a lot of manual labour. [1] psql+readline, pg_dump etc. are a breeze compared to crusty Oracle tools; psql feels distinctly modern compared to MySQL's crummy interpreter. [2] Nobody else has this, I believe, except possibly Ingres and NonStop SQL. This means you can do a "begin transaction", then issue "create table", "alter table", etc. ad nauseum, and in the mean time concurrent transactions will just work. Beautiful for atomically upgrading a production server. Oracle, of course, commits after each DDL statements. [3] PostgreSQL can be extended with new domain types, stored-procedure languages (eg., PL/Python, PL/Perl), functions (eg., dblink, fuzzystrmatch, cube), and indexes (GiST, GIN). Together this allows projects such as TSearch2 and PostGIS to be implemented as separate extensions to PostgreSQL. Alexander.
В списке pgsql-general по дате отправления: