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 1u4heH-006AxN-DO for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Apr 2025 14:52:29 +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 1u4heF-00BS0H-3K for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Apr 2025 14:52:27 +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 1u4heE-00BS09-QB for pgsql-hackers@lists.postgresql.org; Tue, 15 Apr 2025 14:52:27 +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 1u4heC-000EKc-0Y for pgsql-hackers@postgresql.org; Tue, 15 Apr 2025 14:52:27 +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 53FEq9tp1570496; Tue, 15 Apr 2025 10:52:09 -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: <67FDA91C.1060909@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> <3112950.1743984111@sss.pgh.pa.us> <67F31F20.6090706@acm.org> <3291225.1743993461@sss.pgh.pa.us> <67FDA91C.1060909@acm.org> Comments: In-reply-to Chapman Flack message dated "Mon, 14 Apr 2025 20:32:28 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1570494.1744728729.1@sss.pgh.pa.us> Date: Tue, 15 Apr 2025 10:52:09 -0400 Message-ID: <1570495.1744728729@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Chapman Flack writes: > On 04/06/25 22:37, Tom Lane wrote: >> BTW, I feel a little uncomfortable with the idea that we're adding >> dependencies on objects that are explicitly mentioned nowhere in the >> pg_proc entry. > Pursuing that idea a bit further, was there a compelling original reason > the column in pg_proc had to be protrftypes and not just protransforms? The problem from a PL's standpoint is "given this input or output of type FOO, should I transform it, and if so using what?". So the starting point has to be a type not a transform. The lookups are implemented by get_transform_tosql and get_transform_fromsql, and if you look at those you find that the protrftypes data is used as a filter before attempting a pg_transform lookup. If the pg_proc entry contained transform OIDs we'd have to filter after the lookup, which is pretty inefficient, especially if you expect that the normal case is that there's not an applicable transform. So I agree with storing protrftypes. Maybe we should also have stored a parallel array of transform OIDs, but it'd be just to make the dependency more obvious, and maybe it's not worth the storage space. regards, tom lane