Re: WIP: Rework access method interface

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Petr Jelinek <petr(at)2ndquadrant(dot)com>
Cc: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: WIP: Rework access method interface
Date: 2015-09-20 14:18:32
Message-ID: 956.1442758712@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Petr Jelinek <petr(at)2ndquadrant(dot)com> writes:
> On 2015-09-18 14:58, Alexander Korotkov wrote:
>> After, further personal discussion with Teodor, we decided that
>> amvalidate is out of scope for this patch.
>> It's not evident what should we validate in amvalidate and which way. I
>> think if we need amvalidate it should be subject of separate patch.

> But why is it not evident? We do the validations in regression tests,
> even if we just copy those then it's enough for a start.

I think the main reason this question is in-scope for this patch is
precisely the problem of what do we do about the regression tests.

I'm not in favor of exposing some SQL-level functions whose sole purpose
is to support those regression test queries, because while those queries
are very useful for detecting errors in handmade opclasses, they're hacks,
and always have been. They don't work well (or at all, really) for
anything more than btree/hash cases. It'd be better to expose amvalidate
functions, even if we don't yet have full infrastructure for them.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2015-09-20 14:23:05 Re: 9.3.9 and pg_multixact corruption
Previous Message Alexander Korotkov 2015-09-20 14:17:03 Re: WIP: Rework access method interface