Re: access numeric data in module

Tom-
I understand that you are concerned about future maintenance costs vs
benefits of this change. I hope that I can address those concerns. An
important thing to note is that there are two different structures that
represent numeric values:
* NumericData is an opaque structure that is defined in numeric.c. It
is this struct that is used to store values. The patch I submitted has this
structure remain opaque and in numeric.c. Its internals are messy and
subject to future changes. I agree that third parties should not have
access to this. Of note is that the type Numeric is a typedef of
NumericData*.
* NumericVar is a user-friendly structure that already exists. It is
this structure that I propose moving to numeric.h. There are functions that
exist to convert it to and from NumericData. It is these functions that I
propose giving access to.

What the patch boils down to is the movement of NumericVar to numeric.h
along with function declarations for the basic function to work with it and
a few pre-processor declarations.

I agree that there is the potential for future maintenance costs here.
However, any future changes to NumericData would necessitate updating the
code to convert to and from NumericVar regardless of the proposed changes.
I think that this small increase in costs is outweighed by the benefits of
allowing third parties to access this powerful datatype.

As for the reason that I would like to make this change: I am the
maintainer of the PL/Haskell extension. (It allows the use of Haskell code
as a procedural language. https://github.com/ed-o-saurus/PLHaskell) In the
extension, users can currently pass several Postgres types and also have
the function return them. This is accomplished by using the functions and
macros that convert between Datums and C data types. (For example
DatumGetFloat8 and Float8GetDatum to handle double-precision floating point
values) I would like to add support for the use of the numeric type to the
extension. To this end, I would need to create a Haskell type that mirrors
the Postgres numeric type. Passed Haskell values would be instantiated by
reading the data from Postgres. Conversely, returned values would be
converted to the Postgres type. Internally, users would be able to perform
mathematical operations with the Haskell values like any other type.
Currently, there is no way for a third-party extension to get needed
information about numeric values or build new numeric values. The proposed
changes would remedy this.

An alternative approach would be to make available calls to read and
create numeric data. However, as the NumericVar struct already exists, I
feel that utilizing it is the more natural approach.

What do you think?
-Ed

On Sat, Mar 1, 2025 at 3:32 PM Ed Behn <ed(at)behn(dot)us> wrote:

> Tom-
> I think that I can allay your concerns. Please give me a day or so to
> put together my more complete thoughts on the matter. I'll be in touch.
>
> -Ed
>
> On Sat, Mar 1, 2025 at 11:33 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Ed Behn <ed(at)behn(dot)us> writes:
>> >> There is actually no new code. Code is simply moved from numeric.c to
>> >> numeric.h.
>>
>> I will absolutely not hold still for that. It would mean that any
>> time we want to think about messing with the contents of numerics,
>> we need to examine more or less the whole Postgres code base to see
>> what else is poking into those structures.
>>
>> If we must do something like this, then a separate header
>> "numeric_internal.h" or something like that would reduce the blast
>> radius for changes. But IMO you still haven't made an acceptable case
>> for deciding that these data structures aren't private to numeric.c.
>> What behaviors do you actually need that aren't accessible via the
>> existing exported functons?
>>
>> regards, tom lane
>>
>