> This is /finally/ being addressed, although (very) belatedly. The
> Pg core
> dev team always argued that replication was an add-on and should not
> form
> part of the core (ie, similar nonsense excuses the MySQL team used for
> "add-ons" such as triggers, etc).
I believe the developer stance is more the same than you seem to
imagine. The upcoming developments allow replication utilities to tie
in at a deeper and more effective level, and with that new replication
solutions will come along. But I do not think there is any goal to
implement a single replication solution within core and not support
external solutions.
The point of the PostgreSQL developer stance is that until something
can be done correctly, even if it's a lot more work, it's sometimes
better not to do at all. It was recognized early on that if we tried
to figure out the replication puzzle ourself, it would invariably be
complex and never ideally suited for every situation. It would cost a
lot of resources that the team really needed to spend elsewhere at the
time.
MySQL's stance on things like triggers and subselects and so on is
*not* that at all. They recognize that a proper implementation would
be complicated and take a lot of time, so they strongly want to avoid
it, and make lame excuses a lot. When they do finally get around to
implementing something, they have traditionally done it in a broken or
lazy way - e.g. you cannot have two triggers on the same type of
action on the same table, instead you must write a wrapper function
that calls other functions; subselects are always evaluated
independently meaning they usually equate to "horribly slow", there's
a lot of bugs, etc.
I prefer the way PostgreSQL development has been going, personally. :)
Cheers,
--
Casey Allen Shobe
Database Architect, The Berkeley Electronic Press
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
No comments:
Post a Comment