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