Tom Lane <tgl@sss.pgh.pa.us> writes:
> Gregory Stark <stark@enterprisedb.com> writes:
>> Simon Riggs <simon@2ndQuadrant.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!