I looked through all the information_schema stuff, and found a few more
nits.
The CHECK_CONSTRAINTS view should use pg_get_constraintdef() function
rather than consrc, for the same reasons as psql should (I haven't fixed
the latter yet, but will soon).
There are several views that display pg_type.typname directly. I wonder
whether any of these ought to be using format_type() instead. It won't
matter for the views that only show domains, but several could
potentially show standard types. Don't we want the output to be
"character" rather than "bpchar"?
It would be a small efficiency boost to use UNION ALL rather than UNION
where possible.
"READ COMMITED" should be "READ COMMITTED" in sql_implementation_info.
In sql_sizing, MAXIMUM COLUMNS IN SELECT should be 1664
(MaxTupleAttributeNumber).
Several views get fixed pg_class OIDs like this: AND d.refclassid = (SELECT oid FROM pg_class WHERE relname =
'pg_class')
This is unsafe --- suppose a user creates a table named pg_class in one
of his own schemas? The SELECT would return multiple rows, causing a
runtime error. What I would recommend is coding these like AND d.refclassid = 'pg_catalog.pg_class'::regclass
which is schema-safe and also rather more efficient, since the planner
will see this as a simple constant instead of a sub-query.
The ELEMENT_TYPES view doesn't work --- it returns zero rows. After
some fooling around I think it's a simple typo: the line AND (n.nspname, x.objname, x.objtype, x.objtypeid) IN
should be AND (n.nspname, x.objname, x.objtype, x.objdtdid) IN
regards, tom lane