Re: WIP: Rework access method interface - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: WIP: Rework access method interface
Date
Msg-id 20150825153601.GE5232@alvherre.pgsql
Whole thread Raw
In response to Re: WIP: Rework access method interface  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: WIP: Rework access method interface  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Jim Nasby wrote:
> On 8/24/15 9:49 AM, Alexander Korotkov wrote:
> >2) Non-index access methods reuse pg_class.relam but don't reuse pg_am.
> >This violates relational theory because single column reference multiple
> >tables.
> >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.
> >
> >I'd say we already have precedent of #2. It's pg_depend which reference
> >objects of arbitrary types.
> >In the #3 we really shouldn't keep any specific to index am in pg_am.

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

> 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.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: WIP: Rework access method interface
Next
From: Jim Nasby
Date:
Subject: Re: Error message with plpgsql CONTINUE