Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> Petr Jelinek wrote:
>> On 2015-07-13 00:36, Tom Lane wrote:
>>> PS: now that I've written this rant, I wonder why we don't redesign the
>>> index AM API along the same lines. It probably doesn't matter much at
>>> the moment, but if we ever get serious about supporting index AM
>>> extensions, I think we ought to consider doing that.
>> I think this is very relevant to the proposed sequence am patch as well.
> Hmm, how would this work? Would we have index AM implementation run
> some function that register their support methods somehow at startup?
Well, registration of new index AMs is an unsolved question ATM anyhow.
But what I'm imagining is that pg_am would reduce to about two columns,
amname and a handler function OID, and everything else that constitutes
the API for AMs would get moved down to the C level. We have to keep that
catalog because we still need index AMs to have OIDs that will represent
them in pg_opclass etc; but we don't need to nail the exact set of AM
interface functions into the catalog. (I'm not sure whether we'd want
to remove all the bool columns from pg_am. At the C level it would be
about as convenient to have them in a struct returned by the handler
function. But it's occasionally useful to have those properties
visible to SQL queries.)
I'm not clear on whether sequence AMs would need explicit catalog
representation, or could be folded down to just a single SQL function
with special signature as I suggested for tablesample handlers.
Is there any need for a sequence AM to have additional catalog
infrastructure like index AMs need?
> Hopefully we're not going to have the index AMs become shared libraries.
Why not? If they can't be that, any claim that we've solved index AM
extensibility seems pretty weak.
> In any case, if indexes AMs and sequence AMs go this route, that
> probably means the column store AM we're working on will probably have
> to go the same route too.
It's worth considering anyway. The FDW API has clearly been far more
successful than the index AM API in terms of being practically usable
by extensions.
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
