Re: Drop type "smgr"?

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Thu, Feb 28, 2019 at 7:08 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I agree that smgrtype as it stands is pretty pointless, but what
>> will we be using instead to get to those other implementations?

> Our current thinking is that smgropen() should know how to map a small
> number of special database OIDs to different smgr implementations

Hmm. Maybe mapping based on tablespaces would be a better idea?

> Unlike the ancestral code, it wouldn't need to appear in
> catalogs or ever be seen or typed in by users so there still wouldn't
> be a use for this type.

Yeah, the $64 problem at this level is that you don't really want
to depend on catalog contents, because you cannot do a lookup to
find out what to do. So I agree that we're pretty unlikely to
resurrect an smgr type per se. But I'd been expecting an answer
mentioning pg_am OIDs, and was wondering how that'd work exactly.
Probably, it would still be down to some C code having hard-wired
knowledge about some OIDs ...

regards, tom lane