On Sun, Sep 20, 2015 at 5:02 PM, Petr Jelinek <p...@2ndquadrant.com> wrote:

> 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

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

Reply via email to