Re: Transparent column encryption - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: Transparent column encryption
Date
Msg-id CAGECzQSTrmJDK_a7qgjS=kbKnrbdvZWVMHtYotBjqcdZN5snmQ@mail.gmail.com
Whole thread Raw
In response to Re: Transparent column encryption  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Transparent column encryption  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: fix tablespace handling in pg_combinebackup
Next
From: Alvaro Herrera
Date:
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands