Re: access numeric data in module

On Mon, Sep 9, 2024 at 1:25 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> We have changed numeric's internal representation in the past, and
> I'd like to keep the freedom to do so again. There's been discussion
> for example of reconsidering the choice of NBASE to make more sense
> on 64-bit hardware. Yeah, maintaining on-disk compatibility limits
> what we can do there, but not as much as if some external module
> is in bed with the representation.

I disagree with the idea that a contrib module looking at the details
of a Numeric value means we can't make these kinds of updates.

> > Even if it were, an extension author is
> > completely entitled to say "hey, I'd rather have access to an unstable
> > API and update my code for new releases" and we should accommodate
> > that. If we don't, people don't give up on writing the code that they
> > want to write -- they just cut-and-paste private declarations/code
> > into their own source tree, which is WAY worse than if we just put the
> > stuff in a .h file.
>
> IMO it'd be a lot better if numeric.c exposed whatever functionality
> Ed feels is missing, while keeping the contents of a numeric opaque.

We could certainly expose a bunch of functions, but I think that would
actually be a bigger maintenance burden for us than just exposing some
of the details that are currently private to numeric.c. It would also
presumably be less performant, since it means somebody has to call a
function rather than just using a macro.

Also, this seems to me to be holding the numeric data type to a
different standard than other things. For numeric, we have
NumericData, NumericChoice, NumericShort, and NumericLong as structs
that define the on-disk representation. They're in numeric.c. But
ArrayType is in array.h. RangeType is in rangetypes.h. MultiRangeType
is in multirangetypes.h. PATH and POLYGON are in geo_decls.h. inet and
inet_data are in inet.h. int2vector and oidvector are in c.h (which
seems like questionable placement, but I digress). And there must be
tons of third-party code out there that knows how to interpret a text
or bytea varlena. So it's not like we have some principled
project-wide policy of hiding these implementation details. At first
look, numeric seems like an outlier.

--
Robert Haas
EDB: http://www.enterprisedb.com