Re: issue about information_schema REFERENTIAL_CONSTRAINTS

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