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

Reply via email to