On 2015-09-18 14:58, Alexander Korotkov wrote:
On Wed, Sep 16, 2015 at 8:44 PM, Teodor Sigaev <teo...@sigaev.ru <mailto:teo...@sigaev.ru>> wrote:validate_opclass was renamed to amvalidate. 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.
If you mean that it's not obvious what are all the possible things that amvalidate should validate in the future, then yes, that will always be the case though. I think better solution would be to provide more granular validation interface in the C api (i.e. have amvalidateopclass etc). We can still have just one SQL exposed function called amvalidate which will call all those C interfaces that are supported by current version (I agree that those interfaces like amvalidateopclass should accept just Oid).
-- 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
