Re: access numeric data in module - Mailing list pgsql-hackers

From Robert Haas
Subject Re: access numeric data in module
Date
Msg-id CA+TgmobyHf6A0ULnQZGKOm9c4_6XD9+zxLiORamSLr8UmXxTZA@mail.gmail.com
Whole thread Raw
In response to Re: access numeric data in module  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: access numeric data in module
Re: access numeric data in module
List pgsql-hackers
On Mon, Sep 9, 2024 at 10:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Ed Behn <ed@behn.us> writes:
> > I want to be able to have a function received and/or return numeric data.
> > However, I'm having trouble getting data from Datums and building Datums to
> > return. numeric.h does not contain the macros to do this. They are in
> > numeric.c.
>
> > Is there a way to access the values in the numeric structures? If not,
> > would a PR to move macros to numeric.h be welcome in the next commitfest?
>
> It's intentional that that stuff is not exposed, so no.
>
> What actual functionality do you need that numeric.h doesn't expose?

I don't agree with this reponse at all. It seems entirely reasonable
for third-party code to want to have a way to construct and interpret
numeric datums. Keeping the details private would MAYBE make sense if
the internal details were changing release to release, but that's
clearly not the case. Even if it were, an extension author is
completely entitled to say "hey, I'd rather have access to an unstable
API and update my code for new releases" and we should accommodate
that. If we don't, people don't give up on writing the code that they
want to write -- they just cut-and-paste private declarations/code
into their own source tree, which is WAY worse than if we just put the
stuff in a .h file.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: SPI_connect, SPI_connect_ext return type
Next
From: Andrew Dunstan
Date:
Subject: Re: Jargon and acronyms on this mailing list