Re: Some more information_schema issues

Tom Lane writes:

> 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).

True. Btw., is there a particular value in pg_get_constraintdef always
printing double pairs of parentheses for CHECK constraints?

> 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"?

typname is used in those contexts where the type name appears together
with a schema name. In those cases you cannot use the result of
format_type.

> It would be a small efficiency boost to use UNION ALL rather than UNION
> where possible.

Good idea.

> "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

OK.

> 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

OK.

--
Peter Eisentraut peter_e(at)gmx(dot)net