From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Transparent column encryption |
Date: | 2023-03-24 18:12:01 |
Message-ID: | 20230324181201.s4x356sktvkadicn@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-03-23 14:54:48 +0100, Peter Eisentraut wrote:
> On 22.03.23 10:00, Peter Eisentraut wrote:
> > > I get that for the type, but why do we need the typmod duplicated as
> > > well?
> >
> > Earlier patch versions didn't do that, but that got really confusing
> > about which type the typmod really belonged to, since code currently
> > assumes that typid+typmod makes sense. Earlier patch versions had three
> > fields (usertypid, keyid, encalg), and then I changed it to (usertypid,
> > usertypmod, keyid) and instead placed the encalg into the real typmod,
> > which made everything much cleaner.
>
> 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?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Jelte Fennema | 2023-03-24 18:14:39 | Re: running logical replication as the subscription owner |
Previous Message | Melanie Plageman | 2023-03-24 17:27:45 | Re: Should vacuum process config file reload more often |