Re: WIP: Rework access method interface
От | Alexander Korotkov |
---|---|
Тема | Re: WIP: Rework access method interface |
Дата | |
Msg-id | CAPpHfdvKqi=J2oxyruGt1DzhWYL=fyzs6_0epi3=5+3jK_SDJg@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 7:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> I think that's likely for the best anyway; there are too many catalogs
>> that think a pg_am OID identifies an index AM. Better to create other
>> catalogs for other types of AMs.
> That means we won't be able to reuse pg_class.relam as a pointer to the
> AM-of-the-other-kind either.
Hm. So one way or the other we're going to end up violating relational
theory somewhere. OK, I yield: let's say that pg_am has amname, amkind,
amhandler, and nothing else. Then we will need SQL functions to expose
whatever information we think needs to be available to SQL code.
There is second revision of this patch. Changes are so:
* AmRoutine was renamed to IndexAmRoutine assuming there could be other access methods in the future.
* amhandlers now return index_am_handler pseudotype.
* CHECK_PROCEDUREs are now is the place of original GET_REL_PROCEDUREs.
* amstrategies, amsupport, amcanorderbyop, amstorage, amkeytype are in both pg_am and IndexAmRoutine. Consistence of amhandler answer and pg_am tuple is checking.
* Some comments and refactoring.
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Вложения
В списке pgsql-hackers по дате отправления: