Hello,
Am Donnerstag, 14. März 2024, 15:17:58 CET schrieb Tom Lane:
> I wouldn't be concerned about relying on numeric_mul (or any of the
> other functions underlying standard operators). They're undocumented
> only because documenting both the functions and the operators would
> bloat the documentation to little purpose. Using one makes your code
> not so portable to non-Postgres DBMSes, but you already crossed that
> bridge by deciding to use a custom aggregate.
thank you for clearifying this. We're not too concerned about portability. Let's face the facts: Porting a reasonably complex database and the application using it from one DBMS to another will almost certainly introduce an awful lot of portability issues (f.e. the pseudo-types (big)serial, upserts, differences in merge implementations, progammability, and so on). My main concern was, that undocumented features sometimes tend to change without notice, since users are not expected to use them..
> A bigger question is whether this implementation actually has the
> properties you want --- notably, maybe you should be using type
> float8 not numeric. Numeric would get pretty slow and be carrying
> an awful lot of decimal places by the end of the query, I fear.
This needs to be checked on our side. I was expecting, that using an aggregate this way would be significantly faster than using exp(sum(log())). Though we're not multiplying too many lines in a statement, if using the aggregate slows down performance, we should propably stick the old way doing it.
Best regards!
--
MfG Jan
