Re: Could postgres be much cleaner if a future release skipped backward compatibility?

Поиск
Список
Период
Сортировка
От Aidan Van Dyk
Тема Re: Could postgres be much cleaner if a future release skipped backward compatibility?
Дата
Msg-id 20091020003742.GZ30699@oak.highrise.ca
обсуждение исходный текст
Ответ на Re: Could postgres be much cleaner if a future release skipped backward compatibility?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Could postgres be much cleaner if a future release skipped backward compatibility?  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
* Tom Lane <tgl@sss.pgh.pa.us> [091019 18:45]:
> Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
> > Would postgres get considerably cleaner if a hypothetical 9.0 release
> > skipped backward compatibility and removed anything that's only
> > maintained for historical reasons?
> 
> Yeah, and our user community would get a lot smaller too :-(
> 
> Actually, I think any attempt to do that would result in a fork,
> and a consequent splintering of the community.  We can get away
> with occasionally cleaning up individual problematic behaviors
> (example: implicit casts to text), but any sort of all-at-once
> breakage would result in a lot of people Just Saying No.

I don't know... What if this hypothetical "baggage-free" version came
with configurable syncrhonous master-slave replication, writable CTEs,
and everything ;-)

Couple it with a libpq/protocol increase that allows fixing of the
various warts of the current connection (like encoding, etc), and you
still have a *very* attractive platform...

And then just do the rename official to Postgres, and people can support
both PostgreSQL, warts and all, or Postgres, the super-duper
database-to-rule-them-all...

;-)

/me crawls back into his hole

a.

-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: per table random-page-cost?
Следующее
От: KaiGai Kohei
Дата:
Сообщение: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))