On 2018-06-14 16:10:42 -0400, Tom Lane wrote:
> Andres Freund <andres@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