Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qdgnR-004Ot4-IY for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Sep 2023 00:53:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qdgnO-005b9W-KQ for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Sep 2023 00:53:26 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qdgnO-005b8y-9F for pgsql-hackers@lists.postgresql.org; Wed, 06 Sep 2023 00:53:26 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qdgnK-002xn5-OO for pgsql-hackers@lists.postgresql.org; Wed, 06 Sep 2023 00:53:24 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 3860rHBJ1397252; Tue, 5 Sep 2023 20:53:17 -0400 From: Tom Lane To: Vik Fearing cc: "David G. Johnston" , Alvaro Herrera , Pg Hackers , Peter Eisentraut , Peter Eisentraut Subject: Re: information_schema and not-null constraints In-reply-to: <091fee86-6878-8791-574d-8497e79beb82@postgresfriends.org> References: <202309051715.7ghhtqh76hyw@alvherre.pgsql> <091fee86-6878-8791-574d-8497e79beb82@postgresfriends.org> Comments: In-reply-to Vik Fearing message dated "Wed, 06 Sep 2023 01:35:24 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1397250.1693961597.1@sss.pgh.pa.us> Date: Tue, 05 Sep 2023 20:53:17 -0400 Message-ID: <1397251.1693961597@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Vik Fearing writes: > On 9/6/23 00:14, David G. Johnston wrote: >> I'm not all that for either A or B since the status quo seems workable. > Pray tell, how is it workable? The view does not identify a specific > constraint because we don't obey the rules on one side and we do obey > the rules on the other side. It is completely useless and unworkable. What solution do you propose? Starting to enforce the spec's rather arbitrary requirement that constraint names be unique per-schema is a complete nonstarter. Changing the set of columns in a spec-defined view is also a nonstarter, or at least we've always taken it as such. If you'd like to see some forward progress in this area, maybe you could lobby the SQL committee to make constraint names unique per-table not per-schema, and then make the information_schema changes that would be required to support that. In general though, the fact that we have any DDL extensions at all compared to the standard means that there will be Postgres databases that are not adequately represented by the information_schema views. I'm not sure it's worth being more outraged about constraint names than anything else. Or do you also want us to rip out (for starters) unique indexes on expressions, or unique partial indexes? regards, tom lane