From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Transparent column encryption |
Date: | 2023-03-24 10:23:34 |
Message-ID: | 1dae2a23-a962-a0b1-d66a-cba9cd6cdd61@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 23.03.23 16:55, Robert Haas wrote:
> On Thu, Mar 23, 2023 at 9:55 AM Peter Eisentraut
> <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
>> I thought about this some more. I think we could get rid of
>> attusertypmod and just hardcode it as -1. The idea would be that if you
>> ask for an encrypted column of type, say, varchar(500), the server isn't
>> able to enforce that anyway, so we could just prohibit specifying a
>> nondefault typmod for encrypted columns.
>>
>> I'm not sure if there are weird types that use typmods in some way where
>> this wouldn't work. But so far I could not think of anything.
>>
>> I'll look into this some more.
>
> I thought we often treated atttypid, atttypmod, and attcollation as a
> trio, these days. It seems a bit surprising that you'd end up adding
> columns for two out of the three.
Internally, we use all three. But for reporting to the client
(RowDescription message), we only have slots for type and typmod. We
could in theory extend the protocol to report the collation as well, but
it's probably not too interesting.
From | Date | Subject | |
---|---|---|---|
Next Message | brar | 2023-03-24 10:37:48 | Re: doc: add missing "id" attributes to extension packaging page |
Previous Message | Alvaro Herrera | 2023-03-24 09:45:03 | Re: doc: add missing "id" attributes to extension packaging page |