Re: access numeric data in module - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: access numeric data in module
Date
Msg-id F56E3B76-3438-4950-830F-41CDD9DC7466@justatheory.com
Whole thread Raw
In response to Re: access numeric data in module  (Ed Behn <ed@behn.us>)
List pgsql-hackers
Hello Hackers,

On Dec 14, 2025, at 09:10, Ed Behn <ed@behn.us> wrote:

>     I'm wondering what the status of this patch is. (https://commitfest.postgresql.org/patch/5623/)
>     I am, of course, eager to be able to move forward with work on my side that requires it and would love to see it
approved.If there are still any concerns, please let me know and I can attempt to address them.  

The patch looks quite straightforward to me; I see Jelte signed on to review it, but I get the impression that it’s
probablycompletely fine as a patch. The question is whether the committers actually want it, and there’s clearly some
disagreementthere. I find your explanation of how NumericVar is already an abstraction, therefore limiting the
challengesof changing the internal representation of NumericData, but I also see that its structure is pretty specific
tothe Postgres type: 

```c
typedef struct NumericVar
{
    int            ndigits;        /* # of digits in digits[] - can be 0! */
    int            weight;            /* weight of first digit */
    int            sign;            /* NUMERIC_POS, _NEG, _NAN, _PINF, or _NINF */
    int            dscale;            /* display scale */
    NumericDigit *buf;            /* start of palloc'd space for digits[] */
    NumericDigit *digits;        /* base-NBASE digits */
} NumericVar;
```

That all feels somewhat internal-y to me, but maybe that’s just because I don’t understand it, and would have to study
quitea lot to get there. 

The problem I’d like to see solved is related. I maintain pg_clickhouse, and wrote code to convert between the
ClickHouseDecimal structure and the Postgres Numeric structure. I ended up adding stringification to the ClickHouse C++
libraryDecimal type[1] and passing it to numeric_in. 

This feels inefficient, and may or may not be, but it would be much easier for this use case --- and, I suspect, other
extensionsthat need to convert between data types, surely a lot of FDWs and PLs --- if there were more constructors for
theNumeric type than just parsing the string representation. 

Would it make sense to add constructors for some common use cases? I’m thinking something similar to the various
timestampconstructors, like time_t_to_timestamptz()[2]. Something like this would help my use case: 

Numeric int64_scale_to_numeric(int64 num, size_t scale);
Numeric int128_scale_to_numeric(int64 high_num, int64 low_num, size_t scale);

These would assume that the scale defines where the decimal point goes into the resulting Numeric, e.g.,

    int64_scale_to_numeric(2342342334, 4)

Would define the Number 234234.2334.

I don’t know how common this pattern is, however; maybe not so common? If so, then having NumericVar made public, as
yourpatch proposes, would at least allow me to learn how it works and build my own conversion functions. 

IOW, I would very much like to see some ways to make it easier to covert to and from Numeric values, or at least to
exposethe data structures to simplify implementation of such conversions in extensions. 

Best,

David


[1]: https://github.com/ClickHouse/clickhouse-cpp/pull/451
[2]:
https://github.com/postgres/postgres/blob/094b61ce3ebbb1258675cb9b4eca9198628e2177/src/backend/utils/adt/timestamp.c#L1808-L1829


Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: some Page/PageData const stuff
Next
From: Peter Eisentraut
Date:
Subject: Re: remove pg_restrict workaround