Re: WIP: Rework access method interface

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: WIP: Rework access method interface
Date: 2015-08-25 15:36:01
Message-ID: 20150825153601.GE5232@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-08-25 15:50:43 Re: Error message with plpgsql CONTINUE
Previous Message Jim Nasby 2015-08-25 15:27:31 Re: WIP: Rework access method interface