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

Simon Riggs wrote:
> 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.

Languages are quite different. People already know language X, so they
want to use it for stored procedures too. Or they want to interface
other libraries or functionality available in language X. There's no
such argument with indexams. Also, PL handlers are not as tightly
integrated into the rest of the system, no need for low-level page
access, for example, which is why it's easier to have a generic
interface for them. There's also less issues with concurrency and
version-compatibility.

> 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.

Yeah, I'd like to see all those datatypes too. But I'd presume that
audio, video and bioinformatics indexing could all be implemented using
GiST. You don't want to write an indexam from scratch for every data type.

> ... - 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?

I don't see how ripping out hash indexes from core and pushing it into
an external module where it could use the rmgr plugin mechanism would
help to add WAL-logging to it. If someone wants to implement WAL-logging
for hash indexes, just do it, and send a patch.

> 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.

This is an open source project. There's already a lot of people writing
their thesis and whatnot using PostgreSQL, having no problem modifying
the code as they see fit to try completely novel things. We're not
banning or blocking that. On the contrary, that's great! Anyone can
download the source code, modify it, and publish a patch. Others will
find the patch interesting and embrace it, or not. *That's* how this
project moves forward.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com