On Sat, 1 Mar 2025 at 17:33, Tom Lane <tgl@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
