On 2015-11-02 23:28, Tom Lane wrote:
Alvaro Herrera <alvhe...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
