It seems to me, that amvalidate method of AM should get as argument only Oid of operator family. Layout and meaning of amproc/amop fields are differ for different AM and there isn't an AM which implements all possible features.
After, further personal discussion with Teodor, we decided that amvalidate is out of scope for this patch. It's not evident what should we validate in amvalidate and which way. I think if we need amvalidate it should be subject of separate patch. The attached patch exposes index access method parameters to SQL using following fucntions: * get_am_param_oid(oid, text) * get_am_param_int(oid, text) * get_am_param_bool(oid, text)
Hmm, we might want these functons in any case (although I think just one function which would return all am params would be better).
But why is it not evident? We do the validations in regression tests, even if we just copy those then it's enough for a start
The reason is that those validations were used only in regression tests yet. It wasn't used for user-defined operator classes. User might define invalid opclass and then alter it to valid. Or user might upgrade opclass in two steps where intermediate step is invalid. This is why I think validating opclasses in CREATE/ALTER command is not evident since it changes user visible behavior and compatibility.
Simultaneously, implementing new API function just for regression tests doesn't seem to worth it for me.
------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
