Re: Fallback table AM for relkinds without storage

On Mon, Feb 22, 2021 at 05:19:37PM -0800, Andres Freund wrote:
> This doesn't seem like an advantage to me. Isn't this just pushing logic
> away from a fairly obvious point into an AM that one would expect to
> never actually get called?
>
> If we want to go down this path what's the justification for have
> relkind awareness inside the AM? If we want it, we should give FDWs
> their own tableam.

Agreed, I am not completely comfortable with passing down any
knowledge of the relkind down to the AM itself.

> And we should do the same for sequences (that'd imo be a much nicer
> improvement than this change in itself).

Sequences just use the existing heap AM, so you mean to drop from
relcache.c anything specific to sequences when initializing the
relation cache and set pg_class.relam accordingly, right? That makes
sense for consistency with the rest.

> If we were to go for separate AMs I think we could consider implementing
> most of their functionality in one file, to avoid needing to duplicate
> the functions that error out.

Yep, definitely. No issues with that.

> And I'd vote for not naming it no_storage - to me that sounds like a
> name you'd give "blackhole_am". This concept kinda reminds me of
> pseudotypes - so maybe we should just name it pseudo_am.c or such?

For the file name, using something like pseudo_handler.c or similar
would be fine, I guess. However, if we go down the path of one AM per
relkind for the slot callback, then why not just calling the AMs
foreign_table_am, view_am and part_table_am? This could be coupled
with sanity checks to make sure that AMs assigned to those relations
are the expected ones.

blackhole_am is not the best fit for that IMO. It already exists, but
I would be fine to change this code, of course:
https://github.com/michaelpq/pg_plugins/tree/master/blackhole_am
--
Michael