Hello Hackers, On Dec 14, 2025, at 09:10, Ed Behn <[email protected]> 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 probably completely fine as a patch. The question is whether the committers actually want it, and there’s clearly some disagreement there. I find your explanation of how NumericVar is already an abstraction, therefore limiting the challenges of changing the internal representation of NumericData, but I also see that its structure is pretty specific to the 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 quite a 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 ClickHouse Decimal structure and the Postgres Numeric structure. I ended up adding stringification to the ClickHouse C++ library Decimal 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 extensions that need to convert between data types, surely a lot of FDWs and PLs --- if there were more constructors for the Numeric 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 timestamp constructors, 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 your patch 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 expose the 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
signature.asc
Description: Message signed with OpenPGP
