On Thu, Feb 16, 2023 at 01:35:54PM -0800, Andres Freund wrote: > But why do we need it? Most SQL callable functions don't need to be careful > about not leaking O(1) memory, the exception being functions backing btree > opclasses. > > In fact, the detailed memory management often is *more* expensive than just > relying on the calling memory context being reset. > > Of course, numeric.c doesn't really seem to have gotten that message, so > there's a consistency argument here.
I don't know which final result is better. The arguments go two ways: 1) Should numeric.c be simplified so as its memory structure with extra pfree()s, making it more consistent with more global assumptions than just this file? This has the disadvantage of creating more noise in backpatching, while increasing the risk of leaks if some of the removed parts are allocated in a tight loop within the same context. This makes memory management less complicated. That's how I am understanding your point. 2) Should the style within numeric.c be more consistent? This is how I am understanding this proposal. As you quote, this makes memory management more complicated (not convinced about that for the internal of numerics?), while making the file more consistent. At the end, perhaps that's not worth bothering, but 2) prevails when it comes to the rule of making some code consistent with its surroundings. 1) has more risks seeing how old this code is. -- Michael
signature.asc
Description: PGP signature
