On 2014-10-28 13:06:52 -0400, Tom Lane wrote: > 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.
It'd be entirely politicial. I agree. I'm pretty unhappy with the thought that we end up with several 'for pay' index ams out there. But then, PG is BSD style licensed. What I think we need to make absolutely sure is that we preserve the freedom to tinker with the AM functions. I think we'll very heavily curse ourselves if we can't as easily add new features there anymore. > 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. The problem with doing that is that you not only need to add a row in pg_am, but also pg_depend. And a way to remove that row when the respective extension is dropped. Especially the latter imo changed the landscape a fair bit. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
