On 2015-08-27 15:15, Alexander Korotkov wrote:
On Wed, Aug 26, 2015 at 7:20 PM, Alexander Korotkov
<a.korot...@postgrespro.ru <mailto:a.korot...@postgrespro.ru>> wrote:

    On Wed, Aug 26, 2015 at 6:50 PM, Tom Lane <t...@sss.pgh.pa.us
    <mailto:t...@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
        oid, opclass oid)", but I don't see how to implement it without
        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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to