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 1pGj2U-0000XC-3n for pgsql-bugs@arkaria.postgresql.org; Sat, 14 Jan 2023 16:05:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pGj2S-0003Ym-SS for pgsql-bugs@arkaria.postgresql.org; Sat, 14 Jan 2023 16:05:48 +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 1pGj2S-0003Yb-KO for pgsql-bugs@lists.postgresql.org; Sat, 14 Jan 2023 16:05:48 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pGj2R-0006qO-7e for pgsql-bugs@lists.postgresql.org; Sat, 14 Jan 2023 16:05:48 +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 30EG5j2T1006387; Sat, 14 Jan 2023 11:05:45 -0500 From: Tom Lane To: sky.sravan@gmail.com cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17751: DDL CREATE statement accepts invalid default values for FOREIGN KEY constraint. In-reply-to: <17751-30191fe0c6b1e981@postgresql.org> References: <17751-30191fe0c6b1e981@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Sat, 14 Jan 2023 08:32:15 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1006385.1673712345.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Jan 2023 11:05:45 -0500 Message-ID: <1006386.1673712345@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Bug reporting form writes: > --Create a table photos; > -- set the default value of the foreign key as 50 which does not exist i= n > the users table > CREATE TABLE photos( > id SERIAL PRIMARY KEY, > url VARCHAR(200), > user_id INTEGER DEFAULT 50 REFERENCES users(id) ON DELETE SET DEFAULT > ); > --IF we try to delete any user, we will get an error message > DELETE FROM users WHERE id=3D4; > ERROR: insert or update on table "photos" violates foreign key constrai= nt > "photos_user_id_fkey" > DETAIL: Key (user_id)=3D(1) is not present in table "users". > SQL state: 23503 Hm, what I get is regression=3D# DELETE FROM users WHERE id=3D4; ERROR: insert or update on table "photos" violates foreign key constraint= "photos_user_id_fkey" DETAIL: Key (user_id)=3D(50) is not present in table "users". That seems like exactly the correct behavior to me. If we let the DELETE go through, and install the value 50, that would surely be wrong because now the FK constraint would be violated. But what else would you have it do, refuse the second CREATE TABLE altogether on the grounds that maybe sometime in the future 50 wouldn't be a valid value? That's not an improvement (and it probably is contrary to the SQL spec too). regards, tom lane