From: | "Marko Kreen" <markokr(at)gmail(dot)com> |
---|---|
To: | "Weslee Bilodeau" <weslee(dot)bilodeau(at)hypermediasystems(dot)com> |
Cc: | "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-17 13:34:35 |
Message-ID: | e51f66da0610170634j287665f1hcfda262e1bb778c5@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/16/06, Weslee Bilodeau <weslee(dot)bilodeau(at)hypermediasystems(dot)com> wrote:
> Marko Kreen wrote:
> > The PGP functions happen to do it already - pgp_key_id().
>
> Actually, Tom helped me realize I made a mistake, which I'm following
> his suggestion. Not tying keys to OIDs which change when backup/restored.
Yeah, tying to oids is bad, you should link to names,
preferably schema-qualified. Anyway, that was just off-hand
suggestion.
> [ snip nice description ]
> 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.
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-17 13:46:44 | Re: postgres database crashed |
Previous Message | Sander Steffann | 2006-10-17 13:28:26 | Re: [HACKERS] Anyone using "POSIX" time zone offset capability? |