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 1tzIoz-000Wa2-Me for pgsql-general@arkaria.postgresql.org; Mon, 31 Mar 2025 17:21:13 +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 1tzIoy-009EsP-C9 for pgsql-general@arkaria.postgresql.org; Mon, 31 Mar 2025 17:21:12 +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 1tzIoy-009EsA-0q for pgsql-general@lists.postgresql.org; Mon, 31 Mar 2025 17:21:12 +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.96) (envelope-from ) id 1tzIov-002Gfn-24 for pgsql-general@postgresql.org; Mon, 31 Mar 2025 17:21:11 +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 52VHL7Xl4115258; Mon, 31 Mar 2025 13:21:07 -0400 From: Tom Lane To: Renan Alves Fonseca cc: David Rowley , Evgeny Morozov , pgsql-general Subject: Re: Querying one partition in a function takes locks on all partitions In-reply-to: References: <01020195b987abd3-a008b77d-8c63-4931-80a4-be36a351c8b2-000000@eu-west-1.amazonses.com> <01020195dd9e8337-c912f36d-54ef-4d3c-a00d-5e697b308d33-000000@eu-west-1.amazonses.com> Comments: In-reply-to Renan Alves Fonseca message dated "Mon, 31 Mar 2025 18:41:54 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4115256.1743441667.1@sss.pgh.pa.us> Date: Mon, 31 Mar 2025 13:21:07 -0400 Message-ID: <4115257.1743441667@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Renan Alves Fonseca writes: > There is a Note that says: "The entire body of an SQL function is > parsed before any of it is executed. While an SQL function can contain > commands that alter ..." Yup. > If I understood well [2], then both notes may be discarded together in > the next version. No, that aspect is not changed in the currently-proposed patch: we still do parse analysis of all the queries at the beginning. I'd like to make it work differently eventually, but with feature freeze so close I do not think that'll happen for v18. Thinking a bit more about that, if the initial parse analysis succeeds then the patched code will in fact re-parse before execution if any DDL changes have occurred. So you get at least some of the desired behavioral change. But the example given in the docs would still fail, so I don't feel a need to change the docs yet. regards, tom lane