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
