Re: Drop type "smgr"?
От | Tom Lane |
---|---|
Тема | Re: Drop type "smgr"? |
Дата | |
Msg-id | 29545.1551335838@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Drop type "smgr"? (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Drop type "smgr"?
Re: Drop type "smgr"? |
Список | pgsql-hackers |
Thomas Munro <thomas.munro@gmail.com> writes: > On Thu, Feb 28, 2019 at 7:08 PM Tom Lane <tgl@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
В списке pgsql-hackers по дате отправления: