Re: rmgr hooks and contrib/rmgr_hook

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

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

Well wasn't GIST such an instance until we put it in core? IIRC it lived in
contrib for a long time. It happens that the route they took was to implement
it without recoverability until it was in core then add logging. I suspect we
would lean on any new method to have logging before it was merged in though.

I think the version-mismatch problems are fairly important though which is why
I was suggesting providing checks for that in postgres. Simon's right though
that the plugin could check for it itself.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!