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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
