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: