Re: Transparent column encryption

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Transparent column encryption
Дата
Msg-id ee1429d1-a627-db6b-6e43-60491a50896e@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Transparent column encryption  (Andres Freund <andres@anarazel.de>)
Ответы Re: Transparent column encryption  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 29.03.23 18:24, Andres Freund wrote:
> 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?

One might think that, but the precedent in other equivalent systems is 
that you reference the key and the algorithm separately.  There is some 
(admittedly not very conclusive) discussion about this near [0].

[0]: 

https://www.postgresql.org/message-id/flat/00b0c4f3-0d9f-dcfd-2ba0-eee5109b4963%40enterprisedb.com#147ad6faafe8cdd2c0d2fd56ec972a40

>> (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.

What I mean is that various parts of the system think that typid+typmod 
make sense together.  If the typmod actually refers to usertypid, well, 
the code doesn't know that, so who knows what happens.

Also, with the current proposal, the system is internally consistent: 
pg_encrypted_* can actually look at their own typmod and verify their 
own input values that way, which is what a typmod is for.  This just 
works out of the box.

> I find it a lot less clean to make all non-CEK uses of
> pg_attribute pay the price of storing three new fields.

With the proposed removal of usertypmod, it's only two fields: the link 
to the key and the user-facing type.




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

Предыдущее
От: Zheng Li
Дата:
Сообщение: Re: Support logical replication of DDLs
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pgindent vs. git whitespace check