On Tue, Aug 25, 2015 at 7:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Jim Nasby <jim.na...@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. > 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
