Pluggable Indexes (was Re: rmgr hooks (v2))

On Wed, 2009-01-21 at 14:05 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Latest version of rmgr hooks patch for later review in current
> > commitfest.
>
> I'd like to reject this patch.
...
> The external indexam use case doesn't impress me either, and Tom seems to agree
> (http://archives.postgresql.org/message-id/24006.1221483138@sss.pgh.pa.us).
>
> Plus there's the version incompatibility dangers. Although I think we
> could put in some safeguards and live with it, it does open new
> opportunities for confusion, so I'd rather not go there without a very
> convincing use case.

The original design of Postgres allowed pluggable index access methods,
but that capability has not been brought forward to allow for WAL. This
patch would bridge that gap.

Right now we've got a variety of index types that are *not* flourishing
(hash, bitmap, grouped). If we allow them to develop as separate
projects, then whenever they are ready they can be used with particular
releases. You may doubt the worth of those index types but preventing
other people from building them seems strange.

Why do we have 12+ pluggable languages, but we're not allowed to write
pluggable indexes? Whatever argument you put against it being "too hard"
or dangerous or whatever *also* applies to languages. Yet experience
shows pluggability has resulted in a variety of robust and useful
language types, some that might not have been predicted (PL/Proxy, PL/R
etc). They cover a variety of users and situations. Personally, I'd like
to enable people to come up with audio, video, bioinformatics datatypes
and indexes and I definitely don't want to limit the possibilities
there.

There is no danger here for Core, only opportunity. There *is* danger in
forcing new index designers to fit them into Core - look how unusable
hash indexes are. How can we allow that functionality to continue to
exist in Core and yet block the path by which we might reasonably
correct that?

You don't want pluggable indexes, don't use 'em. But that isn't an
argument against allowing the capability for others. That line of
thought would have led us to banning pluggable languages. We should
respect the roots of this project and look for ways to enable the
advancement of database technology, not limit it to only how far we can
currently see ahead through the fog.

> Plus there's the version incompatibility dangers. Although I think we
> could put in some safeguards and live with it, it does open new
> opportunities for confusion, so I'd rather not go there without a
> very
> convincing use case.

There is danger in every plugin, so not a reasonable objection. Any
badly written external module can kill the database or smash data.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support