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.