Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pgnJy-00037J-TL for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Mar 2023 13:55:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pgnJx-0000bp-Mi for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Mar 2023 13:55:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pgnJw-0000b6-Mk for pgsql-hackers@lists.postgresql.org; Mon, 27 Mar 2023 13:55:37 +0000 Received: from new2-smtp.messagingengine.com ([66.111.4.224]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pgnJs-0003BJ-UL for pgsql-hackers@lists.postgresql.org; Mon, 27 Mar 2023 13:55:36 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 8FF395821D9; Mon, 27 Mar 2023 09:55:30 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 27 Mar 2023 09:55:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1679925330; x= 1679932530; bh=zLz7B7w5h5O9G8VuVRPgVV5aLIR4vEJcW9NKNEHWIEg=; b=F ka9YYNMYInda3uJWpcgiwwMpCEuL53TiY5U4mLNnssm4HzFGrmf75lQJX/2QhmQy g2gWHUxCf8JYruCvDM+1OSq1bfqIWdK4ucPA1kplM6o6qgWjYQRzH+KcJOGjvIFI xRhP+83X5MlqTrVgeHi5irLpQqVJY9fFxdZzELJJjjK70BIIfqnLaHcmJ6ltoyBK b/sniwJORCGVgM1rdPRlPjj9LOJAxGQ6xf6xvJf9Jf4pHutHlr0CrovoUqxKlFOR MQeL/B/pW7/qH9mluVd4BRbUtY7d0y3NksjxGH+ZYOGLeQ7S+1ALe+RnjaOZAJ6W poZmlDcXHLcA8+I27X05Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdehvddgjeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvg hrphhrihhsvggusgdrtghomheqnecuggftrfgrthhtvghrnhepfeejgeehteeuhfevvedu leeufedtjeetiefftedvudfhtdeifefgueettdevgefgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhdrvghishgvnhhtrhgruhht segvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Feedback-ID: i131946ab:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Mar 2023 09:55:29 -0400 (EDT) Message-ID: Date: Mon, 27 Mar 2023 15:55:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: cataloguing NOT NULL constraints To: Alvaro Herrera , Pg Hackers References: <20230315224440.cz3brr6323fcrxs6@alvherre.pgsql> Content-Language: en-US From: Peter Eisentraut In-Reply-To: <20230315224440.cz3brr6323fcrxs6@alvherre.pgsql> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 15.03.23 23:44, Alvaro Herrera wrote: > Here's v5. I removed the business of renaming constraints in child > relations: recursing now just relies on matching column names. Each > column has only one NOT NULL constraint; if you try to add another, > nothing happens. All in all, this code is pretty similar to how we > handle inheritance of columns, which I think is good. This patch looks pretty okay to me now. It matches all the functional expectations. I suggest going through the tests carefully again and make sure all the changes are sensible and all the comments are correct. There are a few places where the behavior of tests has changed (intentionally) but the surrounding comments don't match anymore, or objects that previously weren't created now succeed but then affect following tests. Also, it seems some tests are left over from the first variant of this patch (where not-null constraints were converted to check constraints), and test names or comments should be updated to the current behavior. I suppose we don't need any changes in pg_dump, since ruleutils.c handles that? The information schema should be updated. I think the following views: - CHECK_CONSTRAINTS - CONSTRAINT_COLUMN_USAGE - DOMAIN_CONSTRAINTS - TABLE_CONSTRAINTS It looks like these have no test coverage; maybe that could be addressed at the same time.