Re: WIP: Rework access method interface
От | Tom Lane |
---|---|
Тема | Re: WIP: Rework access method interface |
Дата | |
Msg-id | 15580.1439221620@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: WIP: Rework access method interface (Petr Jelinek <petr@2ndquadrant.com>) |
Ответы |
Re: WIP: Rework access method interface
Re: WIP: Rework access method interface Re: WIP: Rework access method interface |
Список | pgsql-hackers |
Petr Jelinek <petr@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. regards, tom lane
В списке pgsql-hackers по дате отправления: