Re: access numeric data in module

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ed Behn <ed(at)behn(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: access numeric data in module
Date: 2024-09-09 17:00:59
Message-ID: CA+TgmobyHf6A0ULnQZGKOm9c4_6XD9+zxLiORamSLr8UmXxTZA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 9, 2024 at 10:14 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Ed Behn <ed(at)behn(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2024-09-09 17:02:51 Re: Jargon and acronyms on this mailing list
Previous Message Robert Haas 2024-09-09 16:29:20 Re: SPI_connect, SPI_connect_ext return type