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 1snij5-005bqO-Vv for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Sep 2024 18:03:00 +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 1snij4-00GOQR-8c for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Sep 2024 18:02:58 +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 1snij3-00GOQJ-TS for pgsql-hackers@lists.postgresql.org; Mon, 09 Sep 2024 18:02:57 +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.94.2) (envelope-from ) id 1snij0-000LCF-CM for pgsql-hackers@postgresql.org; Mon, 09 Sep 2024 18:02:57 +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 489I2qSR3237079; Mon, 9 Sep 2024 14:02:52 -0400 From: Tom Lane To: Robert Haas cc: Ed Behn , pgsql-hackers@postgresql.org Subject: Re: access numeric data in module In-reply-to: References: <3142462.1725891243@sss.pgh.pa.us> <3213437.1725902702@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Mon, 09 Sep 2024 13:51:59 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <3237077.1725904972.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Mon, 09 Sep 2024 14:02:52 -0400 Message-ID: <3237078.1725904972@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > On Mon, Sep 9, 2024 at 1:25 PM Tom Lane wrote: >> IMO it'd be a lot better if numeric.c exposed whatever functionality >> Ed feels is missing, while keeping the contents of a numeric opaque. > We could certainly expose a bunch of functions, but I think that would > actually be a bigger maintenance burden for us than just exposing some > of the details that are currently private to numeric.c. This whole argument is contingent on details that haven't been provided, namely exactly what it is that Ed wants to do that he can't do today. I think we should investigate that before deciding that publishing previously-private detail is the best solution. > Also, this seems to me to be holding the numeric data type to a > different standard than other things. By that argument, we should move every declaration in every .c file into c.h and be done. I'd personally be happier if we had *not* exposed the other data structure details you mention, but that ship has sailed. If we do do what you're advocating, I'd at least insist that the declarations go into a new file numeric_internal.h, so that it's clear to all concerned that they're playing with fire if they depend on that stuff. regards, tom lane