Tom Lane wrote: > Petr Jelinek <p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
