On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Petr Jelinek <p...@2ndquadrant.com> writes: > > On 2015-08-10 16:58, Alexander Korotkov wrote: > >> That should work, thanks! Also we can have SQL-visible functions to get > >> amsupport and amstrategies and use them in the regression tests. > > > SQL-visible functions would be preferable to storing it in pg_am as > > keeping the params in pg_am would limit the extensibility of pg_am > itself. > > I don't see any particularly good reason to remove amsupport and > amstrategies from pg_am. Those are closely tied to the other catalog > infrastructure for indexes (pg_amproc, pg_amop) which I don't think are > candidates for getting changed by this patch. > > 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. > That answers my question, thanks! ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
