Re: making EXPLAIN extensible

Sami Imseih <samimseih(at)gmail(dot)com> writes:
>> It would be better to add the parameter "type: EXPLAIN_ONLY |
>> ANALYZE_ONLY | BOTH" to the RegisterExtensionExplainOption() routine.
>> This value will be saved inside the ExplainExtensionOption structure and
>> processed by the core inside the ParseExplainOptionList.

> hmm, IIUC, what you are describing is flag that will be limited to
> only check if an option can be used with EXPLAIN_ONLY, ANALYZE_ONLY
> or both. But what about if I have a case to check against between other
> extension options? let's say ExtensionAOptionA and ExtensionAoptionB.
> How would that work with the way you are suggesting?

More generally, I think that's quite a constricted view of what sorts
of checks an extension might need to make. As an example, suppose
an extension's option conflicts with "GENERIC_PLAN on" for some reason
(perhaps it wants to modify the plan).

I think the current hook proposal is fine. It leaves all the
validation work to be done by the extension(s), sure, but the amount
of code required to handle that one case is tiny, and the door is
left open to handle cases we didn't foresee.

regards, tom lane