Stephen Frost <sfr...@snowman.net> writes: > * Andres Freund (and...@2ndquadrant.com) wrote: >> The other thing I'm not sure about is that I'm unconvinced that we >> really want external AMs...
> I was wondering about this also and curious as to if there's been any > prior on-list discussion about this proposal that I've simply missed..? We've touched on the issue a few times, but I don't think there's been any attempt to define a project policy about it. My own thought is that allowing external AMs is simply a natural consequence of PG's general approach to extensibility, and it would be surprising if we were to decide we didn't want to allow that. But having said that, it's quite unclear to me that we need the CREATE/DROP ACCESS METHOD infrastructure proposed here. The traditional theory about that is that if you're competent to develop an AM at all, you can certainly manage to insert a row into pg_am manually. I'm afraid that we'd be adopting and maintaining thousands of lines of code that won't ever come close to pulling their weight in usefulness, or probably ever be fully debugged. (The submitted patch is about 1K lines in itself, and it doesn't appear to address any of the consequences of establishing an expectation that AMs are something that can be dropped or modified. Can you say "cache flush"?) So I'd be inclined to put that part of the patch on the back burner until there are actually multiple externally maintained AMs that could use it. Even then, I'm not sure we want to buy into DROP ACCESS METHOD. I think we *do* need some credible method for extensions to emit WAL records, though. I've not taken any close look at the code proposed for that, but the two-sentence design proposal in the original post sounded plausible as far as it went. So my vote is to pursue the WAL extensibility part of this, but not the additional SQL commands. As for the proposed contrib module, we don't need it to test the WAL extensibility stuff: we could just rewrite some existing core code to emit the "extensible" WAL records instead of whatever it's emitting now. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers