Re: WIP: Rework access method interface

On 2015-08-10 18:16, Alvaro Herrera wrote:
> Tom Lane wrote:
>
>> There are a couple of other pg_am columns, such as amstorage and
>> amcanorderbyop, which similarly bear on what's legal to appear in
>> related catalogs such as pg_opclass.  I'd be sort of inclined to
>> leave those in the catalog as well.  I do not see that exposing
>> a SQL function is better than exposing a catalog column; either
>> way, that property is SQL-visible.
>
> If we do that, it doesn't seem reasonable to use the same catalog for
> other things such as sequence AM, right?  IMO it'd be better to keep the
> catalog agnostic for exactly what each row is going to be an AM for.
>

Yeah I said the same, the question is if we should have pg_am agnostic 
or just assume that it's index AM and let other AM types create separate 
catalogs. Tom seems to prefer the latter, I don't see problem with that, 
except that I would really hate to add more am related columns to 
pg_class. I would not mind having relam pointing to different AM catalog 
for different relkinds but dunno if that's ok for others (it's not 
really normalized design).

We could also keep pg_am agnostic and add pg_index_am for additional 
info about index AMs, but that would make this patch more invasive.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services