Re: WIP: Rework access method interface

On Tue, Aug 25, 2015 at 7:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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.
>

OK. So, as we mentioned before, if we need to expose something of am
parameters at SQL-level then we need to write special functions which would
call amhandler and expose it.
Did we come to the agreement on this solution?

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

Agree. Teach syscache about inheritance would be overengeneering for this
problem.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company