Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> ... btw, what is the point of catalog/opfam_internal.h? I see you added
>> it in b488c580aef4e05f, but it seems quite useless to have split it out
>> as a separate header, since only commands/opclasscmds.c uses it.
> Oh, that slipped in there, didn't it. The JSON DDL-deparse bits need
> it -- last posted by Alex Shulgin here:
> https://www.postgresql.org/message-id/CACACo5Q_UXYwF117LBhjZ3xaMPyrgqnqE%3DmXvRhEfjJ51aCfwQ%40mail.gmail.com
I still don't see any reference to OpFamilyMember in there?
> I suppose it shouldn't have been committed, and be part of the extension
> instead.
Previously, OpFamilyMember was just a transient internal data structure
inside commands/opclasscmds.c. Unless we intended that some chunks of
the code in there be exposed for use by extensions, it's not terribly
clear to me why extensions would need to access this struct. Perhaps
we ought to just revert struct OpFamilyMember back into opclasscmds.c.
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.
regards, tom lane
