Re: WIP: Rework access method interface

On 2015-09-18 14:58, Alexander Korotkov wrote:
> On Wed, Sep 16, 2015 at 8:44 PM, Teodor Sigaev <teodor@sigaev.ru
> <mailto:teodor@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