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  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Re: WIP: Rework access method interface  (Petr Jelinek <petr@2ndquadrant.com>)
Re: WIP: Rework access method interface  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: WIP: Rework access method interface
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: WIP: Rework access method interface