Re: Transparent column encryption

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Transparent column encryption
Date: 2024-04-18 19:00:59
Message-ID: CA+TgmoakADEv1+i3aQ9A8er7uDnb_Ev9RRfb6E7zy64yTQW9+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 18, 2024 at 1:49 PM Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> 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.

I think we're more or less covering the same ground we did on the
other thread here -- in theory I don't love the fact that we never
bump the protocol version when we change stuff, but in practice if we
start bumping it every time we do anything I think it's going to just
break a bunch of stuff without any real benefit.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2024-04-18 19:18:32 Re: pgsql: Fix restore of not-null constraints with inheritance
Previous Message Alvaro Herrera 2024-04-18 18:49:52 Re: Can't find not null constraint, but \d+ shows that