Re: WIP: Rework access method interface

On 2015-08-27 15:15, Alexander Korotkov wrote:
> On Wed, Aug 26, 2015 at 7:20 PM, Alexander Korotkov
> <a.korotkov@postgrespro.ru <mailto:a.korotkov@postgrespro.ru>> wrote:
>
>     On Wed, Aug 26, 2015 at 6:50 PM, Tom Lane <tgl@sss.pgh.pa.us
>     <mailto:tgl@sss.pgh.pa.us>> wrote:
>
>         One thought here is that we might not want to just blindly duplicate
>         the existing pg_am behavior anyway.  For example, the main use
>         of the
>         amstrategies column was to allow validation of pg_amop.amopstrategy
>         entries --- but in 4 out of the 6 existing AMs, knowledge of the
>         AM alone
>         isn't sufficient information to determine the valid set of strategy
>         numbers anyway.  So inventing a "pg_amstrategies(am oid)"
>         function seems
>         like it would be repeating a previous failure.  Not quite sure
>         what to
>         do instead, though.  We could imagine something like
>         "pg_amstrategies(am
>         oid, opclass oid)", but I don't see how to implement it without
>         asking
>         opclasses to provide a validation function, which maybe is a
>         change we
>         don't want to take on here.
>
>
>     Could we add another function to access method interface which would
>     validate opclass?
>     Am could validate this way not only strategies, but also supporting
>     functions. For instance, in GIN, we now require opclass to specify
>     at least one of consistent and triconsistent. ISTM I would be nice
>     to let the access method check such conditions. Also, we would be
>     able to check opclass correction on its creation. Now one can create
>     opclass with missing support functions which doesn't work.
>     In the SQL-level we can create function which validates opclass
>     using this new method. This function can be used in regression tests.
>
>
> Should I try to implement such new access method function, say 'amvalidate'?
>

Makes sense to me to do that, should be probably optional though.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services