Jim C. Nasby wrote:
> 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 requirem
Marko Kreen wrote:
> On 10/16/06, Weslee Bilodeau <[EMAIL PROTECTED]> 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 b
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 le
On 10/16/06, Weslee Bilodeau <[EMAIL PROTECTED]> 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
Marko Kreen wrote:
> On 10/12/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Weslee Bilodeau <[EMAIL PROTECTED]> writes:
>> > It works perfectly so long as I used the same key for all my custom
>> > types. When I want a different key for each type though (so for
>> example,
>> > encrypt credit cards wi
On 10/12/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Weslee Bilodeau <[EMAIL PROTECTED]> writes:
> It works perfectly so long as I used the same key for all my custom
> types. When I want a different key for each type though (so for example,
> encrypt credit cards with one key, addresses with another
Weslee Bilodeau <[EMAIL PROTECTED]> writes:
> It works perfectly so long as I used the same key for all my custom
> types. When I want a different key for each type though (so for example,
> encrypt credit cards with one key, addresses with another, etc) I need a
> way to tell them apart.
[ shrug.
Tom Lane wrote:
> Weslee Bilodeau <[EMAIL PROTECTED]> writes:
>> I'm trying to create a few new types, and based on the type in/out
>> functions will operate a bit differently.
>> For the input function finding the type Oid is easy -
>> Oid our_type_oid = PG_GETARG_OID(1);
>> For output though I'
Weslee Bilodeau <[EMAIL PROTECTED]> writes:
> I'm trying to create a few new types, and based on the type in/out
> functions will operate a bit differently.
> For the input function finding the type Oid is easy -
> Oid our_type_oid = PG_GETARG_OID(1);
> For output though I'm having difficulty fin
I'm trying to create a few new types, and based on the type in/out
functions will operate a bit differently.
For the input function finding the type Oid is easy -
Oid our_type_oid = PG_GETARG_OID(1);
For output though I'm having difficulty finding out the type Oid.
I've tried using getBaseTyp
10 matches
Mail list logo