I want compatability in a whole different direction. Let's get really crazy and rip the db out from under vendor solutions. Let their app with its compiled in Oracle driver communicate with a Pg server. We'll completely void any support contract we have, but at least we'll be Oracle free!<p>Can you imagine just swapping in Postgres under a Peoplesoft deployment? As long as you don't make me actually attempt it, it makes me chuckle.
It will be a success when it fully supports, Object Types, Packages, Autonomous transactions, PL/SQL, and BULK Collect Operations among other features.
I don't get what this is. Is this a postgres fork? An extension? The documentation says it's Version 2 but the docs are rather lacking. Having something providing an "Oracle API" on Postgres would be awesome but not sure if this works like that?
So correct me if I am mis-understanding...<p>it has to be in oracle or pg compatibility mode, so effectively its just an oracle api replacement, but should more or less behave like oracle<p>so the only primary benefit is you stop paying oracle because you just want to leave oracle?<p>It doesn't exactly let you move away from oracle APIs though.<p>It is a big win financially. So good on them, I hope it gets all the traction!
Here is another approach from AWS <a href="https://aws.amazon.com/blogs/aws/goodbye-microsoft-sql-server-hello-babelfish/" rel="nofollow">https://aws.amazon.com/blogs/aws/goodbye-microsoft-sql-serve...</a>
I presume this still requires the postgres drivers to connect but then just accepts Oracle syntax once connected? That seems like a very specialized replacement case -- where I guess the app has a lot of complex reporting logic or a monster amount of stored procs that can't be changed, but the consuming app(s) can change drivers and exception handling for the PG ones