public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Robert Haas <[email protected]>
Cc: Ed Behn <[email protected]>
Cc: [email protected]
Subject: Re: access numeric data in module
Date: Mon, 09 Sep 2024 13:25:02 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+TgmobyHf6A0ULnQZGKOm9c4_6XD9+zxLiORamSLr8UmXxTZA@mail.gmail.com>
References: <CAJBL5DP2emt+WPeCo+YY_ogsGt90-_kRU3weS5YJLQTfNZr72Q@mail.gmail.com>
	<[email protected]>
	<CA+TgmobyHf6A0ULnQZGKOm9c4_6XD9+zxLiORamSLr8UmXxTZA@mail.gmail.com>

Robert Haas <[email protected]> writes:
> On Mon, Sep 9, 2024 at 10:14 AM Tom Lane <[email protected]> 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

view thread (9+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: access numeric data in module
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox