Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id E76AE632653 for ; Wed, 1 Sep 2010 11:23:01 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 19324-08 for ; Wed, 1 Sep 2010 14:22:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from cascavel.ensmp.fr (cascavel.ensmp.fr [194.214.158.227]) by mail.postgresql.org (Postfix) with ESMTP id C1664632306 for ; Wed, 1 Sep 2010 11:22:53 -0300 (ADT) Received: from cri.ensmp.fr (nat-int.cri.ensmp.fr [86.65.170.62]) (authenticated bits=0) by cascavel.ensmp.fr (8.14.3/8.14.3/JMMC-11/Mar/2010) with ESMTP id o81EMnPn027879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Sep 2010 16:22:50 +0200 (MEST) Date: Wed, 1 Sep 2010 16:22:49 +0200 (CEST) From: Fabien COELHO X-X-Sender: fabien@localhost.localdomain Reply-To: Fabien COELHO To: Tom Lane cc: PostgreSQL Bugs List Subject: Re: issue about information_schema REFERENTIAL_CONSTRAINTS In-Reply-To: <2683.1283266019@sss.pgh.pa.us> Message-ID: References: <2683.1283266019@sss.pgh.pa.us> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at cascavel with ID 4C7E61B9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4C7E61B9.000 from nat-int.cri.ensmp.fr/nat-int.cri.ensmp.fr/86.65.170.62/cri.ensmp.fr/ X-Scores-Stats: 4C7E61B9.000 B=0.01651 L=0.22030 G=0.00472 Agree X-j-chkmail-Score: MSGID : 4C7E61B9.000 on cascavel.ensmp.fr : j-chkmail score : . : R=. U=. O=. B=0.005 -> S=0.005 X-j-chkmail-Status: Ham 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, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201009/2 X-Sequence-Number: 27966 Dear Tom, >> The REFERENTIAL_CONSTRAINTS table in the information_schema references a >> constaint through its database/schema/name, but this information is not >> unique, so it may identify several constraints, thus the information >> derived may not be consistent. > > Postgres does not enforce that constraints have unique names within a > schema. The SQL spec does say that they should be unique per-schema, > and the information_schema views are designed on that assumption. Hence a contradiction. > If you use spec-compliant names for your constraints, you won't have a > problem. If you don't, well, the information_schema views will be of > limited use to you. I'm writing a schema analyzer which gives false results. I do not write the constraints, I'm analyzing existing schemas. I cannot change it. >> Suggestion: constraint names could be systematically prefixed with their >> corresponding table so that they are indeed unique, > > We are not going to try to enforce uniqueness. I'm not asking for uniqueness in "pg_catalog", esp as that would break existing applications. I'm suggesting uniqueness in the "information_schema", which can be provided independently by some tweaking in the view construction, I think, for instance by adding the oid of the constraint or maybe the table_name. > This has been debated before, and most people like the current behavior > just fine, or at least better than the alternatives. I do not know "most people". I guess "most people" just do not use the "information_schema", so they really do not care! For the "few people" who do use the information_schema, I can assure you that having a false information is a severe drawback, and it is called a "bug". So at least please fill in this as a "bug" somewhere, even if you do not want to fix it. -- Fabien.