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

Aidan Van Dyk wrote:
> * Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [091019 18:45]:
>> 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 ;-)

I know your joking, but what would actually happen is that the people
maintaining the backwards-compatible fork would simply port over those
features as well, or do the fork after those features have went in. None
of the historical features or warts we maintain for
backwards-compatibility are in the way of those cool new features.

It makes sense to remove old warts whenever they do get in the way. Like
add_missing_from that's been discussed at the moment. Other than that,
there's very little harm in keeping them.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com