Re: Pluggable Indexes - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Pluggable Indexes
Date
Msg-id 1232699835.2327.1078.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Pluggable Indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Pluggable Indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, 2009-01-22 at 18:45 -0500, Tom Lane wrote:

> There are other recent examples of proposed hooks that in fact
> failed to be useful because of some oversight or other, and it was
> not until we insisted on seeing a live use of the hooks that this
> became apparent.  (IIRC, one or both of the planner-related hooks
> that are new in 8.4 had such issues.)

Thank you for your support of the plugin concept.

You make good points and are completely correct about the earlier
plugin. The additional plugin capability was filling a gap that had been
left when the planner plugin was added in 8.3. A similar thing happened
with executor plugins IIRC. So I agree, new and complex plugin APIs need
a working example otherwise they'll be wrong.

In the current case, index APIs are already well known, so that API is
unlikely to be a problem. The actual "rmgr plugin" API is very simple,
since its intention is only to add or edit entries onto the internal
RmgrTable (in memory) after which everything is well defined already.
This is probably the simplest API that has been added in recent times.

I'm happy to make the WAL filter plugin work correctly in all cases. It
was intended as a demonstration only, but if that is a problem it is
easily fixed. One of my clients has requested filtering capability
alongside hot standby, so I will deliver it, even if that is rejected
for reasons outside of my hands (such as timing).

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



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Controlling hot standby
Next
From: Carlos Gonzalez-Cadenas
Date:
Subject: Re: deductive databases in postgreSQL