On Mon, Sep 9, 2024 at 1:25 PM Tom Lane <t...@sss.pgh.pa.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
