Re: WIP: Access method extendability

On Tue, Mar 22, 2016 at 1:26 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> So. Before this version of the patch was posted in Nov 4th 2015, both
> Tom and Heikki had said essentially "CREATE ACCESS METHOD is worthless,
> let's pursue this stuff without those commands".
> http://www.postgresql.org/message-id/54730DFD.2060703@vmware.com (Nov
> 2014)
>

Yes, that's it. In this email Heikki asserts that INSERTs into pg_am tables
in extensions would survive pg_upgrade, because pg_dump will dump CREATE
EXTENSION command which execute extension script.
In my response I noticed that it's not correct. pg_dump in binary upgrade
mode works so that we will miss records in pg_am. I haven't any answer
here.
http://www.postgresql.org/message-id/CAPpHfdsbkNtLchypNGR0Ffu9wLHh__NukDp13qLqUKgTNV_N4A@mail.gmail.com
And, as Petr Jelinek mentioned, there is also problem of dependencies in
DROP EXTENSION.

> http://www.postgresql.org/message-id/26822.1414516012@sss.pgh.pa.us (Oct
> 2014)
>

> And then Alexander posted this version, without any discussion that
> evidenced that those old objections were overridden. What happened
> here? Did somebody discuss this in unarchived meetings? If so, it
> would be good to know about that in this thread.

After that Tom Lane committed very huge patch about rework AM API. One of
aims of this patch was support for CREATE ACCESS METHOD command.
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=65c5fcd353a859da9e61bfb2b92a99f12937de3b
I've initially positioned this patch as refactoring for support CREATE
ACCESS METHOD command.
http://www.postgresql.org/message-id/CAPpHfdtLiSXmXk2b4tW+4+No_1-T0raO5fOYszhO6+Sn2Om+xw@mail.gmail.com
During discussing Tom mentioned future CREATE ACCESS METHOD command.
http://www.postgresql.org/message-id/16164.1439222900@sss.pgh.pa.us
I don't think Tom would put so much efforts in this direction if he would
remain opposed to this command.

I noticed this state of affairs because I started reading the complete
> thread in order to verify whether a consensus had been reached regarding
> the move of IndexQualInfo and GenericCosts to selfuncs.h. But I only
> see that Jim Nasby mentioned it and Alexander said "yes they move";
> nothing else. The reason for raising this is that, according to
> Alexander, new index AMs will want to use those structs; but current
> index AMs only include index_selfuncs.h, and none of them includes
> selfuncs.h, so it seems completely wrong to be importing all the planner
> knowledge embodied in selfuncs.h into extension index AMs.
>
> One observation is that the bloom AM patch (0003 of this series) uses
> GenericCosts but not IndexQualInfo. But btcostestimate() and
> gincostestimate() both use IndexQualInfo, so other AMs might well want
> to use it too.
>
> We could move GenericCosts and the prototype for genericcostestimate()
> to index_selfuncs.h; that much is pretty reasonable. But I'm not sure
> what to do about IndexQualInfo. We could just add forward struct
> declarations for RestrictInfo and Node to index_selfuncs.h. But then
> the extension code is going to have to import the includes were those
> are defined anyway. Certainly it seems that deconstruct_indexquals()
> (which returns a list of IndexQualInfo) is going to be needed by
> extension index AMs, at least ...
>

Thank you for highlighting these issues.

> I've made a few edits to the patch already, but I need to do some more
> testing.

Did you already fix the issues above or do you need me to fix them?

> Particularly I would like to understand the relcache issues to
> figure out whether the current one is right.

Good point. I'll also try to find relcache issues.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company