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
