Tom Lane wrote:
> Petr Jelinek <petr@2ndquadrant.com> writes:
> > On 2015-08-10 17:47, Tom Lane wrote:
> >> I don't see any particularly good reason to remove amsupport and
> >> amstrategies from pg_am. Those are closely tied to the other catalog
> >> infrastructure for indexes (pg_amproc, pg_amop) which I don't think are
> >> candidates for getting changed by this patch.
>
> > Ok, in that case it seems unlikely that we'll be able to use pg_am for
> > any other access methods besides indexes in the future.
>
> I think that's likely for the best anyway; there are too many catalogs
> that think a pg_am OID identifies an index AM. Better to create other
> catalogs for other types of AMs.
That means we won't be able to reuse pg_class.relam as a pointer to the
AM-of-the-other-kind either. I don't think this is the best course of
action. We have the sequence AM patch that already reuses
pg_class.relam to point to pg_seqam.oid, but you objected to that on
relational theory grounds, which seemed reasonable to me. The other
option is to create yet another pg_class column with an OID of some
other AM catalog, but this seems a waste.
FWIW the column store patch we're working on also wants to have its own
AM-like catalog. In our current code we have a separate catalog
pg_colstore_am, but are eagerly waiting for the discussion on this to
settle so that we can just use pg_am and pg_class.relam instead. (The
patch itself is not public yet since it's nowhere near usable, and this
detail is a pretty minor issue, but I thought reasonable to bring it up
here. We're also waiting on upper-planner "path-ification" since it
seems likely that some code will collide there, anyway.)
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
