On Sat, 1 Mar 2025 at 17:33, Tom Lane <t...@sss.pgh.pa.us> wrote: > But IMO you still haven't made an acceptable case > for deciding that these data structures aren't private to numeric.c. > What behaviors do you actually need that aren't accessible via the > existing exported functons?
FWIW in pg_duckdb we would definitely have liked to have access to some of the currently unexposed numeric internals. We vendored in some of the definitions that we required ourselves[1], but it would be very nice if we didn't have to. I cannot speak for Ed's reasoning, but for pg_duckdb the reason we cannot use the many of the already exposed functions are not thread-safe. So we create our own thread-safe way of constructing these functions. Another reason is so we can construct numeric types from int128/uint128 types efficiently. I would be very happy if we'd have these definitions available, even if they would change in a future PG version (that's what you sign up for as an extension author). And indeed as Robert already said, numeric seems to be the only type that has this kind of restriction on viewing the internal representation. [1]: https://github.com/duckdb/pg_duckdb/blob/main/include/pgduckdb/vendor/pg_numeric_c.hpp
