Re: access numeric data in module

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ed Behn <ed(at)behn(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: access numeric data in module
Date: 2025-03-01 22:01:12
Message-ID: CAGECzQTWC-eYa_LuSQ=HcRRjN+vzrKW8bRTD7E3yBW=oj-9DGA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 1 Mar 2025 at 17:33, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ed Behn 2025-03-01 22:25:19 Re: access numeric data in module
Previous Message Tom Lane 2025-03-01 21:23:39 Re: Statistics Import and Export