Re: WIP patch to improve amvalidate functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP patch to improve amvalidate functions
Date
Msg-id 7803.1453346639@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP patch to improve amvalidate functions  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> I'm posting this now just in case anyone has some comments, or quibbles
>> about the overall intent.  In particular, if anyone has an idea for a more
>> thorough missing-objects check on BRIN opfamilies, I would like to hear
>> it.  The fact that there are two kinds of opfamilies with rather different
>> internal consistency requirements is a real pain there, and the check
>> rules I have here are definitely the result of some trial and error.

> Without reading your code: maybe each opfamily framework could itself
> provide a validator function as a separate support procedure (currently
> brin_minmax_validate and brin_inclusion_validate); so the generic BRIN
> amvalidate verifies the basic elements of the opfamily, then hands off
> to the opfamily-framework-specific validator function for additional
> checking.

Yeah, there were already some discussions in the index-AM-API-rewrite
thread about providing ways for individual opclasses to help in checking.
BRIN's not the only AM with an issue --- GIST, GIN, SPGIST all have the
property that only an individual opclass really knows which operator
strategy numbers are valid for it.  OTOH, I'm not certain how important
that is for those AMs, because their opclasses are fairly self-contained.
BRIN seems to have a two-level structure here which makes it more
important to offer cross-checking.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: ALTER TABLE behind-the-scenes effects' CONTEXT
Next
From: Michael Paquier
Date:
Subject: Re: exposing pg_controldata and pg_config as functions