Re: access numeric data in module

Please find attached an updated patch against the current master branch.

-Ed

On Sat, Sep 20, 2025 at 8:11 AM Ed Behn <ed(at)behn(dot)us> wrote:

> Good morning-
> It looks like the proposed change associated with this thread has
> languished (https://commitfest.postgresql.org/patch/5623/) Is there
> anything I can do to get it rolling again?
>
> -Ed
>
> On Sat, Mar 1, 2025 at 5:25 PM Ed Behn <ed(at)behn(dot)us> wrote:
>
>> 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
>>>>
>>>