|From:||Bruce Momjian <bruce(at)momjian(dot)us>|
|To:||Rui DeSousa <rui(at)crazybean(dot)net>|
|Cc:||Benedict Holland <benedict(dot)m(dot)holland(at)gmail(dot)com>, Bear Giles <bgiles(at)coyotesong(dot)com>, Evan Bauer <evanbauer(at)mac(dot)com>, bejita0409(at)yahoo(dot)co(dot)jp, "pgsql-admin(at)lists(dot)postgresql(dot)org" <pgsql-admin(at)lists(dot)postgresql(dot)org>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: How to revoke privileged from PostgreSQL's superuser|
|Views:||Raw Message | Whole Thread | Download mbox|
On Fri, Aug 10, 2018 at 10:34:26PM -0400, Rui DeSousa wrote:
> With that logic then you should use flat files for encrypted data and
> unencrypted data. It’s what was done many moons ago; and its unstructured
> haphazard approach gave rise to RDBMS systems.
> You cannot say that encrypted data does not belong in a RDBMS system… that is
> just false. Hell, I’ve stored blobs in a RDMBS system which could have easily
> been stored in a different system if need be. It’s a design choice and what
> fits the application and budget needs.
> Encrypting sensitive information and storing in the database is a valid use
> case. It may be only a few columns that are encrypted or a complete document
> (blob); there is no need to increase complexity just to move those columns out
> of the database.
I think the point is that it makes sense to store data encrypted in a
database only if it is a payload on another piece of non-encrypted data.
You can't easily index, restrict, or join encrypted data, so it doesn't
have a huge value alone in a database.
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
|Next Message||Bruce Momjian||2018-08-14 19:59:19||Re: How to revoke privileged from PostgreSQL's superuser|
|Previous Message||Debraj Manna||2018-08-14 18:50:27||pg_upgrade failing with error pg_resetxlog no such file|
|Next Message||Jack Cushman||2018-08-14 19:52:37||Re: Duplicating data folder without tablespace, for read access|
|Previous Message||Alvar Freude||2018-08-14 19:15:59||Re: Best Practices for Extensions, limitations and recommended use for monitoring|