Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nWS5x-0000jo-QU for pgsql-hackers@arkaria.postgresql.org; Tue, 22 Mar 2022 00:09:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nWS5w-00028j-Bm for pgsql-hackers@arkaria.postgresql.org; Tue, 22 Mar 2022 00:09:52 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nWS5w-00028a-2n for pgsql-hackers@lists.postgresql.org; Tue, 22 Mar 2022 00:09:52 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nWS5t-0008Uf-GR for pgsql-hackers@lists.postgresql.org; Tue, 22 Mar 2022 00:09:50 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id CFD805C0251; Mon, 21 Mar 2022 20:09:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 21 Mar 2022 20:09:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=W7G5JRkNkNUf8q6jRxCwH3J7u2+bQalHiRSIPY cV0T4=; b=tUSbZMo77W/a8LUj0OW2GjZImp5rnxMNm6xBE0LxtBXzui5zYNeGgP vMXk7YhFfwPU4ESaIVsgNl5J3yNaUvjeyJsnSGMZBtCHTMYg9nxnkEIOmlfoq6xc wqaAsuFWwwtfsWeOXJZhZIv1UG71WrSR528ARwlzKCwmLomK6xmbnGykDlTZ/md6 0V9jbzSMRl6dx2YmB0JmMAIVTHNL4jMD4ukgI24+MRav2nC9yO8/7zYK/u7iE2nk Uy91hC2w36bheCDFKWYP5qwcFO2t3fgdxUqkz0XSEU/7mHF2Hogw1w2tBYuaUBOP nY5GSm26+NY8LTLpGoKtMQ1ld/kJU73A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=W7G5JRkNkNUf8q6jR xCwH3J7u2+bQalHiRSIPYcV0T4=; b=jqjEE7PFDEAQHqzfPaC5YwyReS+JvrvhL WSBsYhQYEeIx4SV8p4dT5EIX4n8XszuLMAj168XQHK+5k8X6T3dNS0G85LXoJh3x tyhKHFsBenaEDLDVbrTfM7MqGfbRSQ22nL02UGD+1JLrBl6SIy+a/Gt+hA6K2/EG O/v3t2heIv/gdoYThxKDc/ctiAiYthSzlRF85AQTHanlxALeWqTppQZCQwa2ZoYp tovz1TSIEPE0S7l6T/z++7WyX9QjgxRz+1jOLtRWyRAi9ySwYHSwPt/qA68yJyhl flChB54XqRM4mCFj8UsWakIGvymWrwGZZiSiYVuSjQMWAYlGhe4yw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudeggedgudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffvuffkfhggtggujgfhsehttdertddttddvnecuhfhrohhmpeetnhgurhgv shcuhfhrvghunhguuceorghnughrvghssegrnhgrrhgriigvlhdruggvqeenucggtffrrg htthgvrhhnpeekleehgeeuvdfhffeggeekgfetueeuleffvddvtdeiveegjeekjefgkeet vedvtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe grnhgurhgvshesrghnrghrrgiivghlrdguvg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 21 Mar 2022 20:09:48 -0400 (EDT) Date: Mon, 21 Mar 2022 17:09:47 -0700 To: Tom Lane Cc: Sofia Kopikova , pgsql-hackers@lists.postgresql.org Subject: Re: [PATCH] Add TOAST support for several system tables Message-ID: <20220322000947.3hehzo6urekrtib2@alap3.anarazel.de> [IFrom: Andres Freund References: <1643112264.186902312@f325.i.mail.ru> <2748770.1646089728@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2748770.1646089728@sss.pgh.pa.us> From: Andres Freund List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-02-28 18:08:48 -0500, Tom Lane wrote: > =?UTF-8?B?U29maWEgS29waWtvdmE=?= 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