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.96) (envelope-from ) id 1vaFYM-005pWn-34 for pgsql-hackers@arkaria.postgresql.org; Mon, 29 Dec 2025 15:53:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vaFYL-00HBCc-1v for pgsql-hackers@arkaria.postgresql.org; Mon, 29 Dec 2025 15:53:02 +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.96) (envelope-from ) id 1vaFYL-00HBCU-0w for pgsql-hackers@lists.postgresql.org; Mon, 29 Dec 2025 15:53:02 +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 1vaFYJ-003Q8n-2N for pgsql-hackers@postgresql.org; Mon, 29 Dec 2025 15:53:01 +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 5BTFqwGn2869013; Mon, 29 Dec 2025 10:52:58 -0500 From: Tom Lane To: Kirill Reshke cc: pgsql-hackers Subject: Re: Define DatumGetInt8 function. In-reply-to: References: Comments: In-reply-to Kirill Reshke message dated "Mon, 29 Dec 2025 16:02:34 +0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2869010.1767023578.1@sss.pgh.pa.us> Date: Mon, 29 Dec 2025 10:52:58 -0500 Message-ID: <2869012.1767023578@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Kirill Reshke writes: > During this rebase resolution, I noticed that there is an Int8GetDatum > function, but there is no DatumGetInt8, which I want to use. All other > inline functions seem to be provided in pairs by postgres.h. So it > looks convenient to define DatumGetInt8 in postgres.h? I would actually turn this around and ask why we have Int8GetDatum? We have no SQL types for which that is well-adapted. I see no uses of Int8GetDatum in our tree, and only three uses of UInt8GetDatum, and all three of those look like type puns to me. (heap_page_items is returning a smallint, and btcharskipsupport should be using CharGetDatum.) So from where I sit these look like an attractive nuisance that we should remove rather than encourage use of. If you have some extension data type for which these make sense, that's fine, but it doesn't mean they should be in core Postgres. regards, tom lane