Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rD4OJ-000oPp-LX for pgsql-bugs@arkaria.postgresql.org; Tue, 12 Dec 2023 15:09:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rD4OH-005jlB-FT for pgsql-bugs@arkaria.postgresql.org; Tue, 12 Dec 2023 15:09:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rD4OH-005jl2-6h for pgsql-bugs@lists.postgresql.org; Tue, 12 Dec 2023 15:09:45 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rD4OE-00Bav1-Hv for pgsql-bugs@lists.postgresql.org; Tue, 12 Dec 2023 15:09:44 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 3BCF9Z552436652; Tue, 12 Dec 2023 10:09:36 -0500 From: Tom Lane To: Aksel Allas cc: Laurenz Albe , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18242: pg_dump with non-superuser from pg14 to pg15 fails on ALTER FUNCTION In-reply-to: References: <18242-89f57a188c7de6c8@postgresql.org> <9ad3c3781f8d89efab1917d1431226f4da79d443.camel@cybertec.at> Comments: In-reply-to Aksel Allas message dated "Tue, 12 Dec 2023 14:51:02 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2436650.1702393775.1@sss.pgh.pa.us> Date: Tue, 12 Dec 2023 10:09:35 -0500 Message-ID: <2436651.1702393775@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Aksel Allas writes: > So it's not possible to fully use pg_dump without manually altering the > output of pg_dump in managed postgreSQL cases? Nope, trying to dump/restore other people's objects as a non-superuser isn't considered supported at the moment. You're not the first to complain about this, but no coherent proposal to improve it has been made. It's not very clear what the supported case ought to be exactly; clearly a zero-privilege user can't succeed at this, but what privileges should be expected? Also it's not clear what problems exist beyond the schema-privilege one, and it's not clear how we could solve the problem(s) without creating other ones. There's a lot of history behind the way that pg_dump does things, so rearranging its choices about how/when to change privileges is scary. regards, tom lane