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 1rSe2d-00F0BV-Mn for pgsql-bugs@arkaria.postgresql.org; Wed, 24 Jan 2024 14:15:48 +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 1rSe2c-005N4P-SJ for pgsql-bugs@arkaria.postgresql.org; Wed, 24 Jan 2024 14:15:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rSaE7-003tvP-FH for pgsql-bugs@lists.postgresql.org; Wed, 24 Jan 2024 10:11:23 +0000 Received: from smtp6-g21.free.fr ([212.27.42.6]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rSaE3-003S2k-Ay for pgsql-bugs@lists.postgresql.org; Wed, 24 Jan 2024 10:11:22 +0000 Received: from zimbra-e1-02.priv.proxad.net (unknown [172.20.243.240]) by smtp6-g21.free.fr (Postfix) with ESMTP id DB72C780368 for ; Wed, 24 Jan 2024 11:11:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr; s=smtp-20201208; t=1706091077; bh=OMpr10fM8sjRtOacrH4cd6lniwIIwccfEiS9qOFbRxQ=; h=Date:From:To:In-Reply-To:References:Subject:From; b=cKC3Xo+hvOcfBxkHqhlOT4IBTfYRDUnC1868701HKAZiv4TNLnQMEf95es6JS8u3Y I/MhXdwbi9YEEm7PIE2hb6d+mC8fWIwg7G1CBnrJOip0Y2OYmV741PUQZOixZHSyAV L/IuyUu9bJccjQqSvF4I+rcddZTnYIBnRv8C21899lcw9FUCEGjYWJ0lT9fBqCNupx ZaukCSCX9Nq48C/1yiN7BOd7kYS/0lowXX9y4rxOupJ4rEx32R3dN+5K01w2d3Xb6b UAXPd9ByInOYF+goF7KJwKSTPYAXSolPlE4J/m9f1yX3VY2WiDl6p7pv9Cs4x21zYg EsG1CAEbXE7Mg== Date: Wed, 24 Jan 2024 11:11:17 +0100 (CET) From: gparc@free.fr To: pgsql-bugs Message-ID: <1142099713.208806083.1706091077854.JavaMail.zimbra@free.fr> In-Reply-To: <18295-0ed0fac5c9f7b17b@postgresql.org> References: <18295-0ed0fac5c9f7b17b@postgresql.org> Subject: Re: BUG #18295: In PostgreSQL a unique index on targeted columns is sufficient to support a foreign key MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [145.242.20.128] X-Mailer: Zimbra 9.0.0_GA_1337 (ZimbraWebClient - FF102 (Linux)/9.0.0_GA_1337) Thread-Topic: BUG #18295: In PostgreSQL a unique index on targeted columns is sufficient to support a foreign key Thread-Index: K9r76zspZthEZONOnmn8oMyNzF6wfw== List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello, any comment ? Regards ----- Mail original ----- De: "PG Bug reporting form" =C3=80: "pgsql-bugs" Cc: "gparc" Envoy=C3=A9: Lundi 15 Janvier 2024 12:37:19 Objet: BUG #18295: In PostgreSQL a unique index on targeted columns is suff= icient to support a foreign key The following bug has been logged on the website: Bug reference: 18295 Logged by: Gilles PARC Email address: gparc@online.fr PostgreSQL version: 16.1 Operating system: Linux Description: =20 Hello, coming from Oracle, I'm surprised to see that in PostgreSQL, a foreign key can be linked to a unique index on the target table and not exclusively to a primary key constraint or UNIQUE constraint. Even if a primary/unique constraint implies the creation of a unique index, semantically, it's not the same. In Oracle, in that case (only unique index on targeted columns), we get the following error :=20 ORA-02270: no matching unique or primary key for this column-list Reading the PostgreSQL documentation, I found this snippet in Chapter 5.4 (https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAIN= TS-FK) :=20 "A foreign key must reference columns that either are a primary key or form a unique constraint. This means that the referenced columns always have an index (the one underlying the primary key or unique constraint);" which seems to suggest that in PostgreSQL also a foreign key should refer t= o a primary/unique constraint on the target table. Is it a bug or an intended feature ? If the latter, I think the doc should be amended to remove any ambiguity. Regards P.S. by the way, I don't know what the SQL standard states about that.