Re: WIP: Rework access method interface

On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Petr Jelinek <petr(at)2ndquadrant(dot)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