Re: [HACKERS] WIP patch to improve amvalidate functions

2016-01-20 Thread Tom Lane
Alvaro Herrera  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


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


Re: [HACKERS] WIP patch to improve amvalidate functions

2016-01-20 Thread Alvaro Herrera
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.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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