Re: Transparent column encryption
От | Peter Eisentraut |
---|---|
Тема | Re: Transparent column encryption |
Дата | |
Msg-id | 71adec5d-28a8-12c2-ccb7-f4eebeed2058@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Transparent column encryption (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: Transparent column encryption
Re: Transparent column encryption |
Список | pgsql-hackers |
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. I'm not sure if there are weird types that use typmods in some way where this wouldn't work. But so far I could not think of anything. I'll look into this some more.
В списке pgsql-hackers по дате отправления: