On Sat, 3 Jan 2026 at 18:14, David E. Wheeler <[email protected]> wrote: > 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.
Yes, it's internally. But to me the whole point of creating an extension (with native code) is so you can access internal things. This is the only type that we're currently hiding the internal structure of, and I don't think numeric is any more special than any of our other complex data types. > 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. There's also numeric_send/recv which allow you to create one using binary representation > 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. Yeah with pg_duckdb I'm in a similar boat. > 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); For pg_duckdb this would not be enough, because those functions would still be using palloc. And I want to convert between types in a multi-threaded environment, which prohibits the use of palloc.
