Re: Transparent column encryption

Поиск
Список
Период
Сортировка
От Jelte Fennema-Nio
Тема Re: Transparent column encryption
Дата
Msg-id CAGECzQSTrmJDK_a7qgjS=kbKnrbdvZWVMHtYotBjqcdZN5snmQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Transparent column encryption  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Transparent column encryption  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, 18 Apr 2024 at 18:46, Robert Haas <robertmhaas@gmail.com> wrote:
> With regard to the Bind message, I suggest that we regard the protocol
> change as reserving a currently-unused bit in the message to indicate
> whether the value is pre-encrypted, without reference to the protocol
> extension. It could be legal for a client that can't understand
> encryption message from the server to supply an encrypted value to be
> inserted into a column. And I don't think we would ever want the bit
> that's being reserved here to be used by some other extension for some
> other purpose, even when this extension isn't used. So I don't see a
> need for this to be tied into the protocol extension.

I think this is an interesting idea. I can indeed see use cases for
e.g. inserting a new row based on another row (where the secret is the
same).

IMHO that means that we should also bump the protocol version for this
change, because it's changing the wire protocol by adding a new
parameter format code. And it does so in a way that does not depend on
the new protocol extension.



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: fix tablespace handling in pg_combinebackup
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands