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@gmx.net