Re: WIP: Rework access method interface
От | Alexander Korotkov |
---|---|
Тема | Re: WIP: Rework access method interface |
Дата | |
Msg-id | CAPpHfdsR8S4vCYqGUFupE==cXd+YF4LbL-Wv-fj5PPEwmw+kMw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: Rework access method interface (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WIP: Rework access method interface
|
Список | pgsql-hackers |
On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.
That answers my question, thanks!
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
В списке pgsql-hackers по дате отправления: