Re: WIP: Access method extendability

On 2014-10-28 13:06:52 -0400, Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Andres Freund (andres@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