Re: WIP: Access method extendability

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-10-28 13:06:52 -0400, Tom Lane wrote:
>> 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.

(1) That's not that hard; initdb makes pg_depend entries from SQL.
(2) You only need a row in pg_depend if you provide a DROP command
that would need to pay attention to it.

> And a way to remove that row when the
> respective extension is dropped.

I'm not at all sold on the idea that we need to support dropping AMs.
I think it'd be fine to consider that installing an AM into a given
database is a one-way operation. Then you just need to insert some
pg_depend entries that "pin" the AM's individual functions, and you're
done.

Yeah, sure, CREATE/DROP ACCESS METHOD would be cleaner. But in this
case I'm not buying the "if you build it they will come" argument.
External AMs *can* be built without any such SQL-level support, and if
there were really much demand for them, there would be some out there.
Let's build the essential WAL support first, and leave the syntactic
sugar till we see some demand.

regards, tom lane