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

From Tom Lane
Subject Re: WIP: Rework access method interface
Date
Msg-id 5064.1440519613@sss.pgh.pa.us
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  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-hackers
Jim Nasby <Jim.Nasby@bluetreble.com> writes:
> On 8/25/15 10:56 AM, Tom Lane wrote:
>> 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.

> Would fields in pg_am be overloaded then?

No, because the proposal was to reduce pg_am to just amname, amkind
(which would be something like 'i' or 's'), and amhandler.  Everything
specific to a particular type of access method would be shoved down to
the level of the C APIs.

> From a SQL standpoint it'd be 
> much nicer to have child tables, though that could potentially be faked 
> with views.

I've looked into having actual child tables in the system catalogs, and
I'm afraid that the pain-to-reward ratio doesn't look very good.
        regards, tom lane



pgsql-hackers by date:

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