Re: Transparent column encryption - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Transparent column encryption
Date
Msg-id 20230329162413.dqih7hrgzralitgr@awork3.anarazel.de
Whole thread Raw
In response to Re: Transparent column encryption  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Transparent column encryption  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
Hi,

On 2023-03-29 18:08:29 +0200, Peter Eisentraut wrote:
> On 24.03.23 19:12, Andres Freund wrote:
> > > I thought about this some more.  I think we could get rid of attusertypmod
> > > and just hardcode it as -1.  The idea would be that if you ask for an
> > > encrypted column of type, say, varchar(500), the server isn't able to
> > > enforce that anyway, so we could just prohibit specifying a nondefault
> > > typmod for encrypted columns.
> >
> > Why not just use typmod for the underlying typmod? It doesn't seem like
> > encrypted datums will need that? Or are you using it for something important there?
>
> Yes, the typmod of encrypted types stores the encryption algorithm.

Why isn't that an attribute of pg_colenckey, given that attcek has been added
to pg_attribute?


> (Also, mixing a type with the typmod of another type is weird in a variety
> of ways, so this is a quite clean solution.)

It's not an unrelated type though. It's the actual typmod of the column we're
talking about. I find it a lot less clean to make all non-CEK uses of
pg_attribute pay the price of storing three new fields.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: what should install-world do when docs are not available?
Next
From: Andres Freund
Date:
Subject: Re: what should install-world do when docs are not available?