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 1tc7w9-00FhNF-Qg for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Jan 2025 19:04:50 +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 1tc7w5-0086kG-Iq for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Jan 2025 19:04:45 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tc7w5-0086k8-9c for pgsql-hackers@lists.postgresql.org; Sun, 26 Jan 2025 19:04:45 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tc7w2-001dk6-2t for pgsql-hackers@lists.postgresql.org; Sun, 26 Jan 2025 19:04: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 50QJ4fjI046877; Sun, 26 Jan 2025 14:04:41 -0500 From: Tom Lane To: Andrey Borodin cc: Michel Pelletier , Pavel Stehule , pgsql-hackers@lists.postgresql.org Subject: Re: Using Expanded Objects other than Arrays from plpgsql In-reply-to: <38A31221-C1C4-4846-9709-D66ACD76E87A@yandex-team.ru> References: <1342498.1729444411@sss.pgh.pa.us> <1445998.1729482404@sss.pgh.pa.us> <2062830.1729625620@sss.pgh.pa.us> <2265411.1729699470@sss.pgh.pa.us> <2354718.1729737539@sss.pgh.pa.us> <2581216.1729794746@sss.pgh.pa.us> <1948345.1730500073@sss.pgh.pa.us> <3797606.1732045516@sss.pgh.pa.us> <647219! ! ! .1736019347@sss.pgh.pa.us> <1417389.1736964543@sss.pgh.pa.us> <3363452.1737483125@sss.pgh.pa.us> <0AC229FA-A3F1-43FD-B0DC-A46A73FEAFF7@yandex-team.ru> <931398.1737905825@sss.pgh.pa.us> <38A31221-C1C4-4846-9709-D66ACD76E87A@yandex-team.ru> Comments: In-reply-to Andrey Borodin message dated "Sun, 26 Jan 2025 22:04:15 +0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46875.1737918281.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sun, 26 Jan 2025 14:04:41 -0500 Message-ID: <46876.1737918281@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andrey Borodin writes: > On 26 Jan 2025, at 20:37, Tom Lane wrote: >> Maybe we should recast it as an action. What do you think of >> "mark_expr_as_assignment_source"? > Sounds better to me. I found no examples of similar functions nether in = pl_gram.y, nor in gram.y, so IMO mark_expr_as_assignment_source() is the b= est candidate. WFM, I'll make it so in next version. > Got it, many thanks for the explanation. I'll see about incorporating more of that in the comments, too. > I wonder if you plan similar optimizations for array_cat(), array_remove= () etc? > + a :=3D a || a; -- not optimizable > Why is it not optimizable? Because there is no support function, because= array_cat() has no support function, or something else? plpgsql won't attempt to optimize it because "a" is referenced twice and there is no support function that might say it's safe anyway. array_cat doesn't currently have any special smarts about expanded arrays, so it's all moot because the arrays would get flattened on the way into it. If we did improve it to be able to cope with expanded arrays, I'm not real sure that it could safely manage an in-place update where the two inputs are the same array --- at the least, some extreme care would be needed to get the right answers. I'm not real excited about optimizing additional array operations anyway. Maybe some more will get done at some point, but I don't see that as part of this work. regards, tom lane