From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Petr Jelinek <petr(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-08-26 16:20:21 |
Message-ID: | CAPpHfdvipSj5dsRfJA7qhR9pjDL+fOr4z1C+C3qP_i-+n6Umaw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 26, 2015 at 6:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
> > OK. So, as we mentioned before, if we need to expose something of am
> > parameters at SQL-level then we need to write special functions which
> would
> > call amhandler and expose it.
> > Did we come to the agreement on this solution?
>
> I think we were agreed that we should write functions to expose whatever
> needs to be visible at SQL level. I'm not sure that we had a consensus
> on exactly which things need to be visible.
>
> One thought here is that we might not want to just blindly duplicate
> the existing pg_am behavior anyway. For example, the main use of the
> amstrategies column was to allow validation of pg_amop.amopstrategy
> entries --- but in 4 out of the 6 existing AMs, knowledge of the AM alone
> isn't sufficient information to determine the valid set of strategy
> numbers anyway. So inventing a "pg_amstrategies(am oid)" function seems
> like it would be repeating a previous failure. Not quite sure what to
> do instead, though. We could imagine something like "pg_amstrategies(am
> oid, opclass oid)", but I don't see how to implement it without asking
> opclasses to provide a validation function, which maybe is a change we
> don't want to take on here.
>
Could we add another function to access method interface which would
validate opclass?
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.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-08-26 16:49:46 | Re: 9.4 broken on alpha |
Previous Message | Andrew Dunstan | 2015-08-26 16:15:48 | Re: Function accepting array of complex type |