Re: Pluggable Indexes (was Re: rmgr hooks (v2)) - Mailing list pgsql-hackers

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