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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
