Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Sep 9, 2024 at 10:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
We have changed numeric's internal representation in the past, and
I'd like to keep the freedom to do so again. There's been discussion
for example of reconsidering the choice of NBASE to make more sense
on 64-bit hardware. Yeah, maintaining on-disk compatibility limits
what we can do there, but not as much as if some external module
is in bed with the representation.
> 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.
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.
regards, tom lane
