Fabien COELHO wrote:
>
> > If you're going to use something which is PostgreSQL-specific, you may
> > as well write your own views or use the "native" tables and views
> > directly.
>
> I wish I could write portable code, if possible:-)
>
> I'm basically writing views on top of the information_schema under the
> assumption that what is expected to be a key is a key. The information
> schema is *useless* otherwise as wrong tuples are built on join, and
> derived information is not reliable.
>
> I guess I must the only actual user of the information_schema, and it will
> soon be back to zero user, which will be fine from the developers point of
> view.
Based on this report and later discussion, I have applied the attached
documentation patch to warn users about the Postgres behavior of
information_schema.referential_constraints.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/doc/src/sgml/information_schema.sgml b/doc/src/sgml/information_schema.sgml
index 52407a7..91c2dd4 100644
*** a/doc/src/sgml/information_schema.sgml
--- b/doc/src/sgml/information_schema.sgml
*************** ORDER BY c.ordinal_position;
*** 3211,3216 ****
--- 3211,3229 ----
</tbody>
</tgroup>
</table>
+
+ <note>
+ <para>
+ The SQL standard requires constraint names to be unique within a
+ schema; <productname>PostgreSQL</productname>, however, does not
+ enforce this restriction. If duplicate-named constraints are
+ stored in the same <productname>PostgreSQL</productname> schema, a
+ standard-compliant query that expects to return one row might
+ return several, one for each matching constraint stored in the
+ specified schema.
+ </para>
+ </note>
+
</sect1>
<sect1 id="infoschema-role-column-grants">
