Re: Drop type "smgr"?

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Drop type "smgr"?
Date: 2019-02-28 07:44:21
Message-ID: CAJrrPGcBwvNHtZBFa24jL7TBuhXkSbxa5mBCX1EBoemRFtnS=Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 28, 2019 at 5:37 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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?
>

Thanks to bringing up this idea of mutliple smgr implementations. I also
thought of implementing our own smgr implementation to support transparent
data encryption on the disk based on tablespace mapping.

Regards,
Haribabu Kommi
Fujitsu Australia

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-02-28 07:46:57 Re: BUG #15623: Inconsistent use of default for updatable view
Previous Message Thomas Munro 2019-02-28 07:39:06 Re: Drop type "smgr"?