> - A much better experience in Java and .NET drivers, including SQL custom data types.

I didn't have any better experience with Oracle drivers in Java. Most of the driver is a soup of hacks exploiting obscure features of both the VM and standard library (both the vm and jdk are "Oracle owned" so I guess I was expecting that), also the source code is not available, so debugging it's a hellish experience.

On the other hand the Postgres JDBC Driver is the most well written and documented driver that I ever saw in Java

I beg to differ, those drivers exist since Java was owned by Sun.

Also Oracle was the first RDMS to support stored procedures in Java.

So source isn't available yet you are able to judge the code quality, interesting.

No, disassembling bytecode isn't a reflection of the quality of the original source code.

Sure it works, and is well tested and mature, and so are most of the jdbc drivers, never had any problem with any jdbc driver, aside of digging to code to understand some not documented behaviours. I don't see why put the Java driver as a benefit point of Oracle, most of the developers problems and issues don't occur at the JDBC level. It might be true for .NET but I'm really supicious if the Oracle support is that better over others

I didn't say code quality, I said usage of obscure and internal hacks from the JVM and JDK

Well, to know which obscure and internal hacks are those one has to read the source code.

Also Oracle drivers also run in other JVMs, so which JVM are they abusing then?

As for why speaking about the drivers, I have had my share of driver issues during the last couple of decades, when going enterprise scale.

> Also Oracle was the first RDMS to support stored procedures in Java.

Who in their right mind would do that ? It's a nightmare on so many levels....

All big boys RDMS support stored procedures in Java, and some of them in .NET as well on their Windows deployments.

Because the alternative is PL/SQL, which is Ada minus 90% of the things that make Ada reliable and powerful.

The only stored procedure language that I consider competitive to PL/SQL is Transact-SQL.

> - A much better experience in Java and .NET drivers, including SQL custom data types.

So I'll admit, I haven't used the Oracle Provider for .NET since 2017.

Oracle.DataAccess is not the friendliest library to work with and I've seen some weird issues with pooling in past use. Devart has a good provider, but somewhat limited in free features (still a better general experience than Oracle's provider, but you don't get all the custom bits unless you pay).

PostgreSQL on the other hand has a very nice ADO Provider in NpgSql. It can look a bit daunting with all the config options offered but overall I'd still say it's a better API experience than Oracle.DataAccess.

> - A much better developer experience for stored procedures, with proper packaging, compilation to native code, graphical debugger.

Oh I do miss Oracle Packages so so much. Yeah, they could be a bit annoying to deal with from a 'gobs of code in one file' standpoint, but it's -so- nice to just have PKG_CUSTOMER, PKG_LOCATION instead of having to scroll through all the individual stored procedures, having to guess whether people named things in a way you could find them...

Edit: For a long time, you could have added - Arguments about how to store a boolean value

But thankfully Oracle finally took care of that in 12.

> compilation to native code, graphical debugger.

You have this on postgresql.

> RAC and distributed transactions across a database cluster

Needed only in telcos where galera would be enough

So where is the graphical debugging support and how do I single step a stored procedure?

I have used distributed transactions at life sciences.

dbeaver and plugin_debugger. For distributed transactions, it all depends on why you need them in the first place but there are multiple solutions in postgres to handle them.

So some third party solution, and not first class support from the RDMS vendor.

That is not the same as using Oracle.

Postgres isn't an RDBMS "vendor." Third-party service providers are who you have relationships with. It's like Linux vs. Windows. You don't have a relationship with "Linux"; you have a relationship with RedHat or Canonical, who take responsibility for integration, support, and maintenance of their upstreams (kernel, core libraries, userland packages, etc.)

Apparently not, otherwise there wouldn't exist something like "The PostgreSQL Global Development Group".

Anyone trying others to adopt their products is a vendor, regardless if they are commercial or open source.

Also Linux is just a kernel, naturally it needs a vendor like RedHat or Canonical to provide an actual product.

Postgres is a RDMS already out of the box.

PGDG is effectively an industry consortium of the aligned interests of corporate members—i.e., the vendors. Things don’t “happen” at the level of PGDG, any more than things happen at the level of the UN. Both organizations are there to create opportunities for consensus between members; but in both organizations, it’s the individual members that then go on to actually do things, mostly without one-another’s help.

The PGDG doesn't really exist in the form you imagine. There certainly isn't corporate members or such. It's just a descriptor for all the developers together - it's not even a well defined legal entity.

Right, the members aren't the corporations; rather, the members are the developers, who happen to mostly work for the corporations that serve as vendors. That's what "corporate membership" looks like in FOSS.

E.g., in most Apache projects originally donated from a corporation, that corporation's employees usually still constitute a majority of the developers.

The corporation(s), in such cases, aren't sponsoring the project in any strict technical/legal sense. Rather, the project is steering and constraining the corporation(s) in their development efforts on their forks/extensions of the project codebase, determining through the project's core maintainership's decisions, what will be accepted/upstreamed from those corporate forks/extensions into the open core, vs. what will have to remain in those forks.

See: Redis vs. Redis Labs; CouchDB vs. Cloudant; Apache BEAM vs. Google Cloud Dataflow; etc.

As answered, pgadmin is first class and supports debugging.

Plugin_debugger is availlable on postgresql.org's repo. And supported by our postgresql support provider. You can of course use pgadmin, the official tool, with this plugin.

You should reassess your critics before posting, I think. The evolution of postgresql is faster and faster.

I have spent 2014 to 2018 doing PostgresSQL deployments alongside Oracle, I know how good those offerings are versus Oracle.

Pushing for those plugins as alternative just shows how little one knows about the feature level of Oracle capabilities.

Indeed and the last two years in postgresql history have been very rich feature wise.

I have managed teams of database administrators for roughly 10 years. And I know that using those arcane features or depending too much on those capabilities has cost millions to my company.

Avoid implementing everything in a database.