Re: WIP: Rework access method interface
От | Petr Jelinek |
---|---|
Тема | Re: WIP: Rework access method interface |
Дата | |
Msg-id | 56385478.90208@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: WIP: Rework access method interface (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2015-11-02 23:28, Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: >> Tom Lane wrote: >>> Regardless of that, I'm a bit skeptical that any of these structs ought >>> to be defined as part of the amapi.h interface. They seem to be making >>> premature judgments as to what an opclass verifier will care about. In >>> any case, tying the opclass verifier API to DDL-command implementation >>> details doesn't seem like a good plan. > >> That's a different argument, with which I don't necessarily disagree. >> I think it's not unlikely that a verifier will want to examine the >> contents of the struct, but I don't think that means we need to expose >> the struct in amapi.h. > > I think we'd be considerably better off to *not* re-use OpFamilyMember > in the verifier API. It's a struct that was only ever designed for > internal use in CREATE/ALTER OPERATOR CLASS. > > I'm kind of inclined to just let the verifiers read the catalogs for > themselves. AFAICS, a loop around the results of SearchSysCacheList > is not going to be significantly more code than what this patch does, > and it avoids presuming that we know what the verifiers will wish to > look at. I like this idea. I didn't like from beginning that verifier is tied to opclass but didn't have better solution, but this seems reasonable. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: