From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Sofia Kopikova <s(dot)kopikova(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [PATCH] Add TOAST support for several system tables |
Date: | 2022-03-22 00:09:47 |
Message-ID: | 20220322000947.3hehzo6urekrtib2@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2022-02-28 18:08:48 -0500, Tom Lane wrote:
> =?UTF-8?B?U29maWEgS29waWtvdmE=?= <s(dot)kopikova(at)postgrespro(dot)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.)
As there has been no progress since this email, I'm marking this CF entry as
returned with feedback for now.
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Yugo NAGATA | 2022-03-22 00:10:21 | Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors |
Previous Message | Yugo NAGATA | 2022-03-22 00:08:15 | Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors |