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
One thought here is that we might not want to just blindly duplicate
the existing pg_am behavior anyway. For example, the main use
amstrategies column was to allow validation of pg_amop.amopstrategy
entries --- but in 4 out of the 6 existing AMs, knowledge of the
isn't sufficient information to determine the valid set of strategy
numbers anyway. So inventing a "pg_amstrategies(am oid)"
like it would be repeating a previous failure. Not quite sure
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
don't want to take on here.
Could we add another function to access method interface which would
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 (firstname.lastname@example.org)
To make changes to your subscription: