Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 8985F632F2D for ; Sun, 5 Sep 2010 15:47:54 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 15224-09 for ; Sun, 5 Sep 2010 18:47:47 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mail.postgresql.org (Postfix) with SMTP id 36F27631153 for ; Sun, 5 Sep 2010 15:47:47 -0300 (ADT) Received: (qmail invoked by alias); 05 Sep 2010 18:47:45 -0000 Received: from a88-115-218-165.elisa-laajakaista.fi (EHLO [10.0.0.101]) [88.115.218.165] by mail.gmx.net (mp066) with SMTP; 05 Sep 2010 20:47:45 +0200 X-Authenticated: #495269 X-Provags-ID: V01U2FsdGVkX18Y3ElNpCAYVI4xsAEbuJEXrLeghSlNNqBifsSkSC NlP5iTjELocOo3 Subject: Re: issue about information_schema REFERENTIAL_CONSTRAINTS From: Peter Eisentraut To: Tom Lane Cc: Alvaro Herrera , Fabien COELHO , PostgreSQL Bugs List In-Reply-To: <26284.1283536406@sss.pgh.pa.us> References: <2683.1283266019@sss.pgh.pa.us> <1283369900.15386.0.camel@vanquo.pezone.net> <1283438419.23199.0.camel@vanquo.pezone.net> <6462.1283454730@sss.pgh.pa.us> <22801.1283525905@sss.pgh.pa.us> <1283535870-sup-2648@alvh.no-ip.org> <26284.1283536406@sss.pgh.pa.us> Content-Type: text/plain; charset="UTF-8" Date: Sun, 05 Sep 2010 21:47:43 +0300 Message-ID: <1283712463.12666.7.camel@vanquo.pezone.net> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201009/41 X-Sequence-Number: 28005 On fre, 2010-09-03 at 13:53 -0400, Tom Lane wrote: > Alvaro Herrera writes: > > Excerpts from Fabien COELHO's message of vie sep 03 13:39:19 -0400 2010: > >> I tried to explained that I'm analyzing other people's schemas. I cannot > >> ask all other people on the planet to rewrite their schemas, I pick them > >> as they are. > > > Maybe you shouldn't be using the information_schema in the first place. > > It would probably be reasonable to put something into chapter 34 of the > docs pointing out this limitation. I'm not sure exactly where though. > Should we invent a "compatibility issues" section in that chapter, > analogous to the ones we have for individual SQL commands? Are there > other issues worth documenting for the information_schema views? A very similar issue is already documented here: http://developer.postgresql.org/pgdocs/postgres/infoschema-triggers.html