On Sun, Feb 18, 2024 at 12:30 PM Laurenz Albe <laurenz.a...@cybertec.at> wrote:
> 1. Schemas and users are not tied together, they are orthoginal concepts. > Just like operating > system users and directories (and indeed all other databases). > Forgot about that one! OTOH, you could say PostgreSQL has tied USERs and ROLEs, while ORACLE didn't :) > 2. In PostgreSQL, there is the important concept of ownership, which is > not tied to the schema. > The owner is the user who created the object. > Personally I find that confusing. I wouldn't mind schema objects all belonging to the one owner. Or being to enforce that, as an opt-in option. Not sure what's the benefits of different owners for a schemas objects are. > > As parting thoughts, let me add that I enjoy PostgreSQL more than > Oracle. And libpq way more than OCI. > > That goes without saying. I have never seen an API as terrible as OCI. > As an aside, IBM has re-implemented the OCI API for DB2. I am sure that > led to serial > quitting and mental illness among IBM's developers. > To be fair, these days, anyone should use https://oracle.github.io/odpi/, not OCI directly. And at the time, OCCI was lagging behind OCI, but maybe it doesn't anymore. We're C++ here, not C. Also, as a C++ dev, I use higher level wrappers, easier, type-safe, just as efficient. My own in both cases. Once you've encapsulated your hard-earned knowledge of the low-level API, you forget about it, good or bad. But when you get a crash in OCI, it's much harder to diagnose it, it being so pointer based and closed source... Plus with the protocol being OSS and documented, one can always write a libpq alternative, be it in Go, Rust, JS/TS, or C++ using ASIO (POC at https://github.com/anarthal/postgres-asio), to fit the client environment better. --DD