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 1oEvrI-000328-Co for pgsql-bugs@arkaria.postgresql.org; Fri, 22 Jul 2022 16:50:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oEvrH-00071H-6b for pgsql-bugs@arkaria.postgresql.org; Fri, 22 Jul 2022 16:50:35 +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 1oEvrG-000718-UU for pgsql-bugs@lists.postgresql.org; Fri, 22 Jul 2022 16:50:34 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oEvrE-0005aI-L4 for pgsql-bugs@lists.postgresql.org; Fri, 22 Jul 2022 16:50:33 +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 26MGoTOA667074; Fri, 22 Jul 2022 12:50:29 -0400 From: Tom Lane To: Dean Rasheed cc: Timo Stolz , PostgreSQL mailing lists , Jonas Reinsch , Laura Schlimmer Subject: Re: If a row-level security policy contains a set returning function, pg_dump returns an incorrect serialization of that policy if the return type of the function was altered In-reply-to: References: <5c91267e-3b6d-5795-189c-d15a55d61dbb@nullachtvierzehn.de> <1983818.1658350464@sss.pgh.pa.us> <130689.1658426324@sss.pgh.pa.us> <182492.1658431155@sss.pgh.pa.us> Comments: In-reply-to Dean Rasheed message dated "Thu, 21 Jul 2022 22:27:38 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <667072.1658508629.1@sss.pgh.pa.us> Date: Fri, 22 Jul 2022 12:50:29 -0400 Message-ID: <667073.1658508629@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Dean Rasheed writes: > On Thu, 21 Jul 2022 at 20:19, Tom Lane wrote: >> Here's a proposed patch for that. I wouldn't consider pushing this >> into released branches, but maybe it's not too late for v15? > That looks reasonable to me. It covers all the cases I could think of > to try, and I can't see any loopholes. +1 for applying it to v15. Thanks for checking it! I had second thoughts about removing the old test cases: that would leave us with no test coverage for the executor's defenses against bad plans. I'm not so foolish as to imagine we'll never introduce another bug that would reach those defenses. So what I did was to adjust those cases to manually delete the new pg_depend entries, allowing us to still test what happens without 'em. Pushed that way. regards, tom lane