Re: Could postgres be much cleaner if a future release skipped backward compatibility? - Mailing list pgsql-hackers

From Aidan Van Dyk
Subject Re: Could postgres be much cleaner if a future release skipped backward compatibility?
Date
Msg-id 20091020003742.GZ30699@oak.highrise.ca
Whole thread Raw
In response to Re: Could postgres be much cleaner if a future release skipped backward compatibility?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Could postgres be much cleaner if a future release skipped backward compatibility?  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List 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 by date:

Previous
From: Jeff Davis
Date:
Subject: Re: per table random-page-cost?
Next
From: KaiGai Kohei
Date:
Subject: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))