Re: Transparent column encryption

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Transparent column encryption
Дата
Msg-id 20230324181201.s4x356sktvkadicn@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Transparent column encryption  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: Transparent column encryption  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Melanie Plageman
Дата:
Сообщение: Re: Should vacuum process config file reload more often
Следующее
От: Jelte Fennema
Дата:
Сообщение: Re: running logical replication as the subscription owner