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
