Re: Getting the type Oid in a CREATE TYPE output function
От | Marko Kreen |
---|---|
Тема | Re: Getting the type Oid in a CREATE TYPE output function |
Дата | |
Msg-id | e51f66da0610170634j287665f1hcfda262e1bb778c5@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Getting the type Oid in a CREATE TYPE output function (Weslee Bilodeau <weslee.bilodeau@hypermediasystems.com>) |
Ответы |
Re: Getting the type Oid in a CREATE TYPE output function
Re: Getting the type Oid in a CREATE TYPE output function |
Список | pgsql-hackers |
On 10/16/06, Weslee Bilodeau <weslee.bilodeau@hypermediasystems.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
В списке pgsql-hackers по дате отправления: