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