Re: WIP: Rework access method interface

From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(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-11-03 06:30:16
Message-ID: 56385478.90208@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-11-02 23:28, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> Tom Lane wrote:
>>> Regardless of that, I'm a bit skeptical that any of these structs ought
>>> to be defined as part of the amapi.h interface. They seem to be making
>>> premature judgments as to what an opclass verifier will care about. In
>>> any case, tying the opclass verifier API to DDL-command implementation
>>> details doesn't seem like a good plan.
>
>> That's a different argument, with which I don't necessarily disagree.
>> I think it's not unlikely that a verifier will want to examine the
>> contents of the struct, but I don't think that means we need to expose
>> the struct in amapi.h.
>
> I think we'd be considerably better off to *not* re-use OpFamilyMember
> in the verifier API. It's a struct that was only ever designed for
> internal use in CREATE/ALTER OPERATOR CLASS.
>
> I'm kind of inclined to just let the verifiers read the catalogs for
> themselves. AFAICS, a loop around the results of SearchSysCacheList
> is not going to be significantly more code than what this patch does,
> and it avoids presuming that we know what the verifiers will wish to
> look at.

I like this idea. I didn't like from beginning that verifier is tied to
opclass but didn't have better solution, but this seems reasonable.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vladimir Borodin 2015-11-03 06:57:52 Re: [HACKERS] Replication slots and isolation levels
Previous Message Haribabu Kommi 2015-11-03 06:19:43 Re: NOTIFY in Background Worker