On 09/09/24 13:00, Robert Haas wrote: > I don't agree with this reponse at all. It seems entirely reasonable > for third-party code to want to have a way to construct and interpret > numeric datums. Keeping the details private would MAYBE make sense if > the internal details were changing release to release, but that's > clearly not the case. 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.
Amen. https://tada.github.io/pljava/preview1.7/pljava-api/apidocs/org.postgresql.pljava/org/postgresql/pljava/adt/Numeric.html The above API documentation was written when the PostgreSQL source comments read "values of NBASE other than 10000 are considered of historical interest only and are no longer supported in any sense". I will have to generalize it a bit more if other NBASEs are now to be considered again. If Tom prefers the idea of keeping the datum layout strongly encapsulated (pretty much uniquely among PG data types) and providing only a callable C API for manipulating it, then I might propose something like the above- linked Java API as one source of API ideas. I think it's worth remembering that most PLs will have their own libraries (sometimes multiple alternatives) for arbitrary-precision numbers, and it's hard to generalize about /those/ libraries regarding what API they will provide for most efficiently and faithfully converting a foreign representation to or from their own. Conversion through a decimal string (a) may not be most efficient, and (b) may not faithfully roundtrip possible combinations of digits, displayScale, and weight. >From Java's perspective, there has historically been a significant JNI overhead for calling from Java into a C API, so that it's advantageous to know the memory layout and keep the processing in Java. There is at last a batteries-included Java foreign-function interface that can make it less costly to call into a C API, but that has only landed in Java 22, which not everyone will be using right away. Regards, -Chap