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 [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
