From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, 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:56:33 |
Message-ID: | 4282.1440518193@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-08-25 16:02:40 | Re: Error message with plpgsql CONTINUE |
Previous Message | Jeff Janes | 2015-08-25 15:52:17 | Re: Resource Owner reassign Locks |