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

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

In response to

Responses

Browse pgsql-hackers by date

  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?