Josh Berkus <j...@agliodbs.com> writes: > Right. And I'm saying that pluggability is PostgreSQL's main reason for > existence, if you look at our place in the future of databases. So it's worth > paying *some* cost, provided that the cost/benefit ratio works for the > particular patch.
I agree that pluggability is a huge deal for Postgres. But note that the interface is critical. If we provided a plugin architecture for functions and operators which was simply a hook where you replaced part of the infrastructure of the parser and executor it would be pointless. Instead we provide an interface where your function has to know as little as possible about the rest of the system. And the parser and executor get enough information about your function that they can do most of the work. That you can create a new operator in Postgres *without* knowing how operators actually are implemented and without worrying about what other operators exist is what makes the feature so useful. This is made a lot harder with WAL because a) it spans the entire cluster, not just a database so any meta-information has to be stored somewhere global and b) the consequences for getting something wrong are so much more dire. The entire cluster is dead and can't even be restored from backup. > To rephrase: I can't judge the rmgr patch one way or the other. I'm only > objecting to the idea expressed by Heikki and others that pluggable indexes > are > stupid and unnecessary. Well we support pluggable indexes -- they just can't be recoverable right now. Presumably if they're merged into the core database they would have recoverability added like how GIST progressed. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
