Re: WIP: Rework access method interface

On 2015-08-10 16:58, Alexander Korotkov wrote:
> On Mon, Aug 10, 2015 at 5:48 PM, Tom Lane <tgl@sss.pgh.pa.us
> <mailto:tgl@sss.pgh.pa.us>> wrote:
>
>     Alexander Korotkov <a.korotkov@postgrespro.ru
>     <mailto:a.korotkov@postgrespro.ru>> writes:
>     > On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek <petr@2ndquadrant.com <mailto:petr@2ndquadrant.com>> wrote:
>     >> I don't understand this, there is already AmRoutine in RelationData, why
>     >> the need for additional field for just amsupport?
>
>     > We need amsupport in load_relcache_init_file() which reads
>     > "pg_internal.init". I'm not sure this is correct place to call am_handler.
>     > It should work in the case of built-in AM. But if AM is defined in the
>     > extension then we wouldn't be able to do catalog lookup for am_handler on
>     > this stage of initialization.
>
>     This is an issue we'll have to face before there's much hope of having
>     index AMs as extensions: how would you locate any extension function
>     without catalog access?  Storing raw function pointers in
>     pg_internal.init
>     is not an answer in an ASLR world.
>
>     I think we can dodge the issue so far as pg_internal.init is
>     concerned by
>     decreeing that system catalogs can only have indexes with built-in AMs.
>     Calling a built-in function doesn't require catalog access, so there
>     should be no problem with re-calling the handler function by OID during
>     load_relcache_init_file().
>
>
> That should work, thanks! Also we can have SQL-visible functions to get
> amsupport and amstrategies and use them in the regression tests.
>

SQL-visible functions would be preferable to storing it in pg_am as 
keeping the params in pg_am would limit the extensibility of pg_am itself.

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