[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-hackers
Subject:    Re: =?UTF-8?B?W1BBVENIXSBBZGQgVE9BU1Qgc3VwcG9ydCBmb3Igc2V2ZXJhbCBzeXN0ZW0g?= =?UTF-8?B?dGFibGVz?=
From:       Tom Lane <tgl () sss ! pgh ! pa ! us>
Date:       2022-02-28 23:08:48
Message-ID: 2748770.1646089728 () sss ! pgh ! pa ! us
[Download RAW message or body]

=?UTF-8?B?U29maWEgS29waWtvdmE=?= <s.kopikova@postgrespro.ru> writes:
> ACL lists in tables may potentially be large in size. I suggest adding TOAST \
> support for system tables, namely pg_class, pg_attribute and \
> pg_largeobject_metadata, for they include ACL columns.

TBH, the idea of adding a toast table to pg_class scares the daylights
out of me.  I do not for one minute believe that you've fixed every
problem that will cause, nor do I think "allow wider ACLs" is a
compelling enough reason to take the risk.

I wonder if it'd be practical to move the ACLs for relations
and attributes into some new table, indexed like pg_depend or
pg_description, so that we could dodge that whole problem.
pg_attrdef is a prototype for how this could work.

(Obviously, once we had such a table the ACLs for other things
could be put in it, but I'm not sure that the ensuing breakage
would be justified for other sorts of objects.)

			regards, tom lane


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic