Re: rmgr hooks and contrib/rmgr_hook

On Mon, 2008-09-15 at 08:52 -0400, Tom Lane wrote:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> > Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> >> Indexes have always been able to be added dynamically. Now they can be
> >> recovered correctly as well.
>
> > Hm, so currently if you want to add a new indexam you can't just insert into
> > pg_am and make them recoverable. You basically have to build in your new index
> > access method into Postgres with the new rmgr. That is annoying and a problem
> > worth tackling.
>
> I concur with Heikki that that's not exactly a compelling use-case.
> I've never heard of anyone building a non-core index AM at all; much
> less trying to use it in a production context. Given the obvious
> potential for version-mismatch-type problems, it's hard to believe
> that anyone ever would try.

The lack of a chicken is not an argument against the use case for an
egg.

But in any case, Bizgres was exactly this case, so they already did. We
just forced the authors to produce a code fork to do it, confusing
people rather than attracting people to Postgres.

We have plugin APIs with possible version mismatches in other contexts,
but I don't see us doing anything about that. In the context of WAL, the
basic WAL format has not changed in about 6 releases, so its been one of
the most stable file formats. Certain message types have changed, but
messages are all independent across rmgrs, so insulated from change.

The version mismatch idea presumes that a code author would structure
their code in two pieces: one to generate the WAL and one to read it.
Seems much more likely to me that authors would have one module
containing both as a way of avoiding the problem altogether. So I'm not
sure what to check, and against what?

When people do write useful plugins in the future they will be
potentially usable with any server at 8.4 or above. If we had had this
feature a few releases ago, we could have made GIN available to earlier
releases, for example.

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