Re: access numeric data in module

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
>>>
>>