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 1rT1m7-00HVFv-5c for pgsql-bugs@arkaria.postgresql.org; Thu, 25 Jan 2024 15:36:20 +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 1rT1m6-000eDd-5W for pgsql-bugs@arkaria.postgresql.org; Thu, 25 Jan 2024 15:36:18 +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 1rT1m5-000eDU-Rh for pgsql-bugs@lists.postgresql.org; Thu, 25 Jan 2024 15:36:17 +0000 Received: from smtp6-g21.free.fr ([2a01:e0c:1:1599::15]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rT1m2-003fbQ-Jl for pgsql-bugs@lists.postgresql.org; Thu, 25 Jan 2024 15:36:17 +0000 Received: from zimbra-e1-02.priv.proxad.net (unknown [172.20.243.240]) by smtp6-g21.free.fr (Postfix) with ESMTP id 470AF780503; Thu, 25 Jan 2024 16:36:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr; s=smtp-20201208; t=1706196971; bh=f+KTDZPC6onb0Ba/FNXORE5vL8DFK2E62849Kcr34qM=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=ut6zpqSFLZn3DzG2KvYCE4tvquMyrdbhgBelJCqbP3D33Ig0SO8x0ZorSIPK/oeJc MT2cUeI6Xnn5VIK14cRyViKPc8Ghe+aHhCvOZekpkMzUtwtSoHrXG3Bin5tf2Cgug7 7nWBkDHXW5pq00e8uy1HGYxNb+GgWZRybW+bnpxQNo1wLxW6tH98GeECaI6ZE6zyOp 3Zt6kr2kKnwugcftss3yplqazGbi5Osv59i+U1gBtf/QUAju2EhJxEKEdO1OhWmH+q 0XTQBErjDZCZtuPh2hTyWVCVpe4vyflht5u3DfvnKNlVR3lsu63kwhZNE+Z7+v3QDz fFTCNc3zB3CFA== Date: Thu, 25 Jan 2024 16:36:11 +0100 (CET) From: gparc@free.fr To: Laurenz Albe Cc: pgsql-bugs Message-ID: <1197950598.222716079.1706196971222.JavaMail.zimbra@free.fr> In-Reply-To: <1963986314.213748462.1706112064903.JavaMail.zimbra@free.fr> References: <18295-0ed0fac5c9f7b17b@postgresql.org> <1142099713.208806083.1706091077854.JavaMail.zimbra@free.fr> <51c67d44ee2c5c888d9842110a27b9f9c329cb5e.camel@cybertec.at> <1963986314.213748462.1706112064903.JavaMail.zimbra@free.fr> 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: 0dct57Jz9cwrHxCCoIyJlx3E4b7hHIdCKvWt List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ----- Mail original ----- > De: "gparc" > =C3=80: "Laurenz Albe" > Cc: "pgsql-bugs" > Envoy=C3=A9: Mercredi 24 Janvier 2024 17:01:04 > Objet: Re: BUG #18295: In PostgreSQL a unique index on targeted columns i= s sufficient to support a foreign key > ----- Mail original ----- > De: "Laurenz Albe" > =C3=80: "gparc" , "pgsql-bugs" > Envoy=C3=A9: Mercredi 24 Janvier 2024 16:28:45 > Objet: Re: BUG #18295: In PostgreSQL a unique index on targeted columns i= s > sufficient to support a foreign key >=20 > On Wed, 2024-01-24 at 11:11 +0100, gparc@free.fr wrote: >> coming from Oracle, I'm surprised to see that in PostgreSQL, a foreign k= ey >> can be linked to a unique index >> on the target table and not exclusively to a primary key constraint or >> UNIQUE constraint. >>=20 >> Is it a bug or an intended feature ? If the latter, I think the doc shou= ld >> be amended to remove any ambiguity. >=20 > Let's say it is an extension of the standard, but I cannot say if that is > intended or not. At any rate, it has been like that for a very long time= , > and changing it might make some users unhappy. >=20 > There is some added value, in that you could reference a unique index > that has an INCLUDE clause: >=20 > CREATE TABLE parent (id integer, payload integer, other integer); >=20 > CREATE UNIQUE INDEX ON parent (id) INCLUDE (payload); >=20 > CREATE TABLE child (id integer REFERENCES parent (id)); >=20 > So it might well be seen as a feature. >=20 > Looking at the source, the function comment suggests that that undocument= ed > feature may be there by accident: >=20 > /* > * transformFkeyCheckAttrs - > * > * Make sure that the attributes of a referenced table belong to a unique > * (or primary key) constraint. Return the OID of the index supporting > * the constraint, as well as the opclasses associated with the index > * columns. > */ >=20 > The comment is speaking about a constraint, not a unique index. >=20 > So perhaps the comment should be updated, along with a note in the docume= ntation > (in ddl.html and ref/create_table.sgml). >=20 >=20 >> P.S. by the way, I don't know what the SQL standard states about that. >=20 > That is simple: since the standard doesn't know indexes, it can only talk > about referencing a constraint. >=20 > Yours, > Laurenz Albe >=20 >=20 > Thanks Laurenz for your detailed reply. > I agree also for an update of the documentation and source code. >=20 > Concerning, the documentation, I propose to modify in > https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAI= NTS-FK > the following sentence : > "A foreign key must reference columns that either are a primary key or fo= rm a > unique constraint. > This means that the referenced columns always have an index (the one unde= rlying > the primary key or unique constraint);" > by > "A foreign key must reference columns that either are a primary key or fo= rm a > unique constraint or are specified in a unique index. > This means that the referenced columns are always backed by a UNIQUE inde= x." >=20 > Regards > Gilles Is this new wording OK for you ? Regards Gilles