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(at)sigaev(dot)ru
> <mailto:teodor(at)sigaev(dot)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