Em qui., 15 de set. de 2022 às 10:30, Daniel Gustafsson <dan...@yesql.se> escreveu:
> > On 15 Sep 2022, at 15:13, Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote: > > > > On 2022-Sep-15, Ranier Vilela wrote: > > > >> Em qui., 15 de set. de 2022 às 09:50, Alvaro Herrera < > >> alvhe...@alvh.no-ip.org> escreveu: > > > >>> These functions you are patching are not in performance-sensitive code, > >>> so I doubt this makes any difference performance wise. I doubt > >>> Microsoft will ever remove these deprecated functions, given its > history > >>> of backwards compatibility, so from that perspective this change does > >>> not achieve anything either. > >> > >> If users don't adapt to the new API, the old one will never really > expire. > > > > If you are claiming that Microsoft will remove the old API because > > Postgres stopped using it, ... sorry, no. > > Also, worth noting is that these functions aren't actually deprecated. The > note in the docs state: > Daniel, I agree that MSDN could be better written. See: "Remarks Windows memory management does not provide a separate local heap and global heap. Therefore, the *LocalAlloc* and GlobalAlloc <https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-globalalloc> functions are essentially the same. The movable-memory flags *LHND*, *LMEM_MOVABLE*, and *NONZEROLHND* add unnecessary overhead and require locking to be used safely. They should be avoided unless documentation specifically states that they should be used. New applications should use the heap functions <https://docs.microsoft.com/en-us/windows/desktop/Memory/heap-functions>" Again, MSDN claims to use a new API. And following the bouncing ball into the documentation they refer to [0] I > read > this: > > As a result, the global and local families of functions are > equivalent > and choosing between them is a matter of personal preference. > IMO, This part has nothing to do with it. regards, Ranier Vilela
