Re: Getting the type Oid in a CREATE TYPE output function

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Weslee Bilodeau <weslee(dot)bilodeau(at)hypermediasystems(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Getting the type Oid in a CREATE TYPE output function
Date: 2006-10-18 17:27:33
Message-ID: 20061018172733.GD85041@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 17, 2006 at 04:34:35PM +0300, Marko Kreen wrote:
> >I'm not sure if anyone else needs something like it, but it allows us to
> >transparently encrypt data directly in the tables. Minimum application
> >changes ('select enc_key' at connection) - the main requirement when
> >working on legacy code that needs to match todays security polices quickly.
>
> Some want row-level access control, then your scheme would not be enough.
>
> Maybe it would be better to avoid combining the keys, instead have
> hidden key in database and several user keys that grant access to that
> key, thus you can revoke access from only some users.
>
> But one thing I suggest strongly - use PGP encryption instead
> of old encrypt()/decrypt(). PGP hides the data much better,
> espacially in case of lot of small data with same key.

Better yet, allow the user to plug in encryption modules. Different
people want different kinds of encryption. For example, I believe credit
card companies require AES192.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-10-18 17:37:54 Re: [HACKERS] query log corrupted-looking entries
Previous Message Tom Lane 2006-10-18 17:24:39 Re: pg_internal.init is hazardous to your health