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 1u1ZwH-004d04-WB for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Apr 2025 00:02:09 +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 1u1ZwF-005RrC-SN for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Apr 2025 00:02:08 +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 1u1ZwF-005Rr3-J8 for pgsql-hackers@lists.postgresql.org; Mon, 07 Apr 2025 00:02:07 +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 1u1ZwE-003MuQ-06 for pgsql-hackers@postgresql.org; Mon, 07 Apr 2025 00:02:06 +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 53701pLn3112951; Sun, 6 Apr 2025 20:01:51 -0400 From: Tom Lane To: Chapman Flack cc: PostgreSQL Hackers , Peter Eisentraut Subject: Re: FmgrInfo allocation patterns (and PL handling as staged programming) In-reply-to: <67F30DDA.4000509@acm.org> References: <67F2B767.9040507@acm.org> <2965818.1743960827@sss.pgh.pa.us> <67F2D87F.1000709@acm.org> <2978258.1743968866@sss.pgh.pa.us> <67F30DDA.4000509@acm.org> Comments: In-reply-to Chapman Flack message dated "Sun, 06 Apr 2025 19:27:22 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3112949.1743984111.1@sss.pgh.pa.us> Date: Sun, 06 Apr 2025 20:01:51 -0400 Message-ID: <3112950.1743984111@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Chapman Flack writes: > Only slightly tangentially: what things count as "objects that depend > on the transform" for purposes of DROP TRANSFORM ... CASCADE / RESTRICT ? > I just now dropped (in 17.4) a transform named in an existing routine's > declaration, with nary a peep. Hmm, really? ProcedureCreate() certainly looks like it creates necessary dependencies, and when I tried it just now, I got the expected failure: regression=# create extension hstore_plperl; CREATE EXTENSION regression=# create function foo(f1 hstore) returns hstore language plperl as 'return f1' transform for type hstore; CREATE FUNCTION regression=# drop extension hstore_plperl; ERROR: cannot drop extension hstore_plperl because other objects depend on it DETAIL: function foo(hstore) depends on transform for hstore language plperl HINT: Use DROP ... CASCADE to drop the dependent objects too. But wait a minute ... if I recreate the function with no TRANSFORM clause, I *still* can't drop the transform: regression=# drop function foo(f1 hstore); DROP FUNCTION regression=# create function foo(f1 hstore) returns hstore language plperl as 'return f1'; CREATE FUNCTION regression=# drop extension hstore_plperl; ERROR: cannot drop extension hstore_plperl because other objects depend on it DETAIL: function foo(hstore) depends on transform for hstore language plperl HINT: Use DROP ... CASCADE to drop the dependent objects too. Looking more closely at ProcedureCreate(), it makes a dependency if a transform *exists* for the argument or result type, whether a TRANSFORM clause is present or not. Surely this is completely bogus? We should be depending on the OIDs mentioned in protrftypes, not more nor less. I'm not quite sure if that somehow explains your results, but it does look like a bug to me. regards, tom lane