On 30.03.23 17:55, Andres Freund wrote:
> I find it very hard to belief that details of the catalog representation like
> this will matter to users. How would would it conceivably affect users that we
> store (key, encryption method) in pg_attribute vs storing an oid that's
> effectively a foreign key reference to (key, encryption method)?
The change you are alluding to would also affect how the DDL commands
work and interoperate, so it affects the user.
But also, let's not drive this design decision bottom up. Let's go from
how we want the data model and the DDL to work and then figure out
suitable ways to record that. I don't really know if you are just
worried about the catalog size, or you find an actual fault with the
data model, or you just find it subjectively odd.
>> The feature is arguably useful without typmod support, e.g., for text. We
>> could ship it like that, then do some work to reorganize pg_attribute and
>> tuple descriptors to relieve some pressure on each byte, and then add the
>> typmod support back in in a future release. I think that is a workable
>> compromise.
>
> I doubt that shipping a version of column encryption that breaks our type
> system is a good idea.
I don't follow how you get from that to claiming that it breaks the type
system. Please provide more details.
