Thomas Munro <thomas.mu...@gmail.com> writes:
> On Thu, Feb 28, 2019 at 7:08 PM Tom Lane <t...@sss.pgh.pa.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
