Tom Lane <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> Simon Riggs <[EMAIL PROTECTED]> 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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
