Josh Berkus wrote: > All, > > I really don't see why we would object to making *anything* pluggable if > someone was willing to write the code to do so. For example, making > storage pluggable would allow PostgreSQL to achieve great new things on > new types of hardware. (yes, I have some idea how difficult this would be) > > For that matter, our pluggable languages, operators, aggregates, and > UDFs are the mainsteam of PostgreSQL adoption -- and as hardware and > technology changes in the future, I believe that our database's > programmability will become the *entire* use case for PostgreSQL. > > So I really can't see any plausible reason to be opposed to pluggable > indexes *in principle*. We should be promoting pluggability whereever > we can reasonably add it. > > Now, like always, that says nothing about the quality of this particular > patch or whether it *really* moves us closer to pluggable indexes.
Plugability adds complexity. Heikki's comment is that adding this patch make the job of creating pluggable indexes 5% easier, while no one is actually working on plugable indexes, and it hard to say that making it 5% easier really advances anything, especially since many of our existing index types aren't WAL-logged. Plugability is not a zero-cost feature. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers