Re: WIP: Rework access method interface

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Jim Nasby wrote:
>> On 8/24/15 9:49 AM, Alexander Korotkov wrote:
>>> 3) Non-index access methods reuse both pg_class.relam and pg_am. This
>>> violates relational theory because we store different objects in the
>>> same table.

> In my reading of the thread, we have a consensus for doing #3, and that
> one gets my vote in any case.

That's what I thought as well.

>> In userspace, table inheritance handles this nicely. Stick a "type" field in
>> the parent so you know what kind of entity each record is, along with all
>> your common fields.

> Yeah, this pattern is not hugely common but it's definitely used in some
> places.  In fact, I would think it is less of a violation of relational
> theory than #2 -- because then relam is always a reference to pg_am,
> instead of sometimes being a reference to some other catalog.  What's
> stored in pg_am is not pg_class' concern; and I think calling pg_am a
> catalog for "access methods" (in a generic way, not only indexes) is
> sound.

I'm good with this as long as all the things that get stored in pg_am
are things that pg_class.relam can legitimately reference.  If somebody
proposed adding an "access method" kind that was not a relation access
method, I'd probably push back on whether that should be in pg_am or
someplace else.

The fact that the subsidiary tables like pg_opclass no longer have
perfectly clean foreign keys to pg_am is a bit annoying, but that's better
than having pg_class.relam linking to multiple tables.  (Also, if we
really wanted to we could define the foreign key constraints as
multicolumn ones that also require a match on amkind.  So it's not *that*
broken.  We could easily add opr_sanity tests to verify proper matching.)
        regards, tom lane