Some more information_schema issues

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