Re: Transparent column encryption

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Transparent column encryption
Дата
Msg-id c79a9f4c-259e-4dd9-1325-15afccb806d1@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Transparent column encryption  (Andres Freund <andres@anarazel.de>)
Ответы Re: Transparent column encryption  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 30.03.23 03:29, Andres Freund wrote:
>> 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
> 
> I'm very much not convinced by that. Either way, there at least there should
> be a comment mentioning that we intentionally try to allow that.
> 
> Even if this feature is something we want (why?), ISTM that this should not be
> implemented by having multiple fields in pg_attribute, but instead by a table
> referenced by by pg_attribute.attcek.

I don't know if it is clear to everyone here, but the key data model and 
the surrounding DDL are exact copies of the equivalent MS SQL Server 
feature.  When I was first studying it, I had the exact same doubts 
about this.  But as I was learning more about it, it does make sense, 
because this matches a common pattern in key management systems, which 
is relevant because these keys ultimately map into KMS-managed keys in a 
deployment.  Moreover, 1) it is plausible that those people knew what 
they were doing, and 2) it would be preferable to maintain alignment and 
not create something that looks the same but is different in some small 
but important details.

>> With the proposed removal of usertypmod, it's only two fields: the link to
>> the key and the user-facing type.
> 
> That feels far less clean. I think loosing the ability to set the precision of
> a numeric, or the SRID for postgis datums won't be received very well?

In my mind, and I probably wasn't explicit about this, I'm thinking 
about what can be done now versus later.

The feature is arguably useful without typmod support, e.g., for text. 
We could ship it like that, then do some work to reorganize pg_attribute 
and tuple descriptors to relieve some pressure on each byte, and then 
add the typmod support back in in a future release.  I think that is a 
workable compromise.



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Images storing techniques
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pgindent vs. git whitespace check