On 2018-06-14 16:10:42 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2018-06-14 15:59:22 +0300, Alexander Korotkov wrote: > >> We already have CREATE ACCESS METHOD command. I think this command > >> should handle that internally. And I don't understand why "ON > >> CONFLICT DO NOTHING". If AM with given name already exists in pg_am, > >> why should we ignore the error? > > > Well, right now an AM containing extension creates things in each > > database (i.e. same scope as extensions). But with shared AMs that > > wouldn't be the case - you might still want to create the extension in > > another database. So we'd need to have CREATE ACCESS METHOD check > > whether already is the same entry, and only delete it on DROP ACCESS > > METHOD if there's no dependencies from other databases... > > I'm not really buying this idea at all, at least not for index AMs, > because you also need a pile of other database-local infrastructure > --- opclasses, operators, functions, etc. Trying to make pieces of > that be shared is not going to end well.
Yea, I do think there's a number of issues around exactly that - in fact I raised them when Robert was talking about the issue before. But I do think there's a few things that are doable without actually needing to invoke any user defined code aside of the AM code itself. E.g. heap pruning / aggressively setting hint bits doesn't need to invoke operators, and I can think of some ways to implement index delete marking that does so without invoking any comparators either. Thus it seems like this'd still allow to implement quite a bit of new useful infrastructure, even though more would be needed. Greetings, Andres Freund