On Sun, Feb 18, 2024 at 12:30 PM Laurenz Albe <laurenz.albe@xxxxxxxxxxx> 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
