Re: access numeric data in module

On Sat, 3 Jan 2026 at 18:14, David E. Wheeler <david(at)justatheory(dot)com> 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.