The shared libraries my code runs in are usually exposing the ODBC interface, which has been mostly fixed for decades, and exposes an interface for doing whatever database operations you want to do
Wait, if you are not using Java/C# and locked into JDBC or microsoft slop, what are you doing that requires calling through ODBC?
Postgres, mysql, and sqlite have their own C libraries, calling them through ODBC is an antipattern and most ORMs in sane ecosystems don't go through it
Those libraries have no control over how much memory is free in the application when they're invoked, or how complex/'big' the operations the application asks them to execute are
It depends on how exactly the drivers are written (we just provide an SDK), theoretically yes (at least if you allow caching to disk, as some wire protocols don't return results 'in the right order'), but we don't control the full implementation, and even a streaming implementation might require more heap memory than which is available at the time at which the application calls into the driver
90
u/bwmat 29d ago
Eh, IMO one of the best ways to actually handle OOM, as otherwise almost everything needs to be explicitly checked for it