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 1u1ZOm-004Uhc-Jc for pgsql-hackers@arkaria.postgresql.org; Sun, 06 Apr 2025 23:27:32 +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 1u1ZOk-004wjG-Q6 for pgsql-hackers@arkaria.postgresql.org; Sun, 06 Apr 2025 23:27:31 +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 1u1ZOk-004wg0-D1 for pgsql-hackers@lists.postgresql.org; Sun, 06 Apr 2025 23:27:30 +0000 Received: from 003.mia.mailroute.net ([199.89.3.6]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u1ZOi-003MfG-18 for pgsql-hackers@postgresql.org; Sun, 06 Apr 2025 23:27:29 +0000 Received: from localhost (localhost [127.0.0.1]) by 003.mia.mailroute.net (Postfix) with ESMTP id 4ZW7mH1ySszlvt1m; Sun, 6 Apr 2025 23:27:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=acm.org; h= content-transfer-encoding:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=mr01; t= 1743982046; x=1746574047; bh=se4fEwIVKwcXI/FPsyaEfci0E8KjNL7Jb6h hJECjGW0=; b=gEKGFhRog30MURLnrZeQDH0qhxP5+VQMKn/aojMbcf2NwlS+pxL l/B0vyTOwXvitfInfSU28tn+uyRGAt/PPBxY2OWp8P7lfa3v6Q7bakZPc9Jw2/uS bt+5E8Y6ynCzgOAVtnu+88MvshqUKdTXyOXrDm+Lh0WvNwWAPizlP/jDR3bFUrnI majZk9Gb+F1mHndSrlRx7a08oBKNN2PbOgCGahC+LnE54pfC+OMC5/fbOPNyHdAY 3f65qWdG7CIhqLs8Dpr3FPGEKB4Lj+YsQxeBwFhMWt06N2h4BWQnsey9Jl8vtvY9 z4uGhEfhhXi81sq1V+7QcfHSLq0VBDJxpaQ== X-Virus-Scanned: by MailRoute Received: from 003.mia.mailroute.net ([127.0.0.1]) by localhost (003.mia [127.0.0.1]) (mroute_mailscanner, port 10029) with LMTP id 6XCFCE7hu6N1; Sun, 6 Apr 2025 23:27:26 +0000 (UTC) Received: from [73.103.120.3] (c-73-103-120-3.hsd1.in.comcast.net [73.103.120.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jcflack@acm.org) by 003.mia.mailroute.net (Postfix) with ESMTPSA id 4ZW7mF1Zjjzlvt1j; Sun, 6 Apr 2025 23:27:23 +0000 (UTC) Subject: Re: FmgrInfo allocation patterns (and PL handling as staged programming) To: Tom Lane References: <67F2B767.9040507@acm.org> <2965818.1743960827@sss.pgh.pa.us> <67F2D87F.1000709@acm.org> <2978258.1743968866@sss.pgh.pa.us> Cc: PostgreSQL Hackers From: Chapman Flack X-Enigmail-Draft-Status: N1110 Message-ID: <67F30DDA.4000509@acm.org> Date: Sun, 6 Apr 2025 19:27:22 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <2978258.1743968866@sss.pgh.pa.us> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 04/06/25 15:47, Tom Lane wrote: > Chapman Flack writes: >> Can a spread-out variadic "any" arg list ever vary >> in length or type on the fly at a single call site? > > Don't think so. 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. I'm not, for now, complaining, as my objective was to make sure my dispatcher noticed that, when dispatching to the routine, and if DROP TRANSFORM had refused, I'd have had to work harder. Right now the dispatcher is only checking before validate or prepare though. If transforms can really just vanish I'd better check even when dispatching to a cached version. I suppose a cached routine could continue merrily along using the vanished transform's functions, as long as they haven't vanished. But once the transform is dropped there's nothing saying you can't drop the functions, and that could get weird. Or, is somehow registering a routine's dependency on a transform something that its PL handler is responsible for doing? I could sort of see that, given that it's the PL that has to make whatever actual transformation happens, happen. But relying on the PL to record the dependency would seem brittle, what with validators not running for sure in all circumstances. Regards, -Chap