And, as an increasing number of 3rd-party tools support PostgreSQL (like Embarcadero) they need a simple comprehensible API for system objects -- more objects than are included in the information_schema.
There are only two choices: Creating a minimal subset tool, which will rely on INFORMATION_SCHEMA (or a schema API as in ODBC) as standardized by SQL specs, or making it specifically for every DBMS, whether using some fancy views or not.
A 3rd party proprietary vendor is not going to learn about OIDs,
Doing it seriously, it probably needs the internal DBMS object identifiers (oid in the case of pgsql), to uniquely identify objects even after a rename. Hiding the OIDs in schema views will reduce their usability.
Regards, Andreas
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
