MIME-Version: 1.0
References: <CADfhSr-pCkbDxmiOVYSAGE5QGjsQ48KKH_W424SPk+pwzKZFaQ@mail.gmail.com>
 <CAFY6G8cgNNw86oPAE6MUWm=sPd7T0xr+5qBJWEtvre2n-wUetg@mail.gmail.com>
 <CAEG8a3JR8quniKWNu4jTJJM_1fNiCPnsEQPCDO+NFtKup7MTbQ@mail.gmail.com>
 <CA+HiwqF+pBaQ5tnH7Mu=7rsNUsq1LSD9WvzCeQJz=2qD5unB0A@mail.gmail.com>
 <CA+HiwqG_PXQqL9TvQFEdyJfB9Wq1-Wm3SFppWHhMg+z2gD_nag@mail.gmail.com>
 <CADfhSr8hYc-4Cz7vfXH_oV-Jq81pyK9W4phLrOGspovsg2W7Kw@mail.gmail.com> <CA+HiwqFhGaQWX+COwv0XM6Co9jFc9=auqDKQXnaST04XAYGrBw@mail.gmail.com>
In-Reply-To: <CA+HiwqFhGaQWX+COwv0XM6Co9jFc9=auqDKQXnaST04XAYGrBw@mail.gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
Date: Fri, 10 Apr 2026 18:13:33 +0900
Message-ID: <CA+HiwqH_gVz_V8nqCf9jjHZkUT=QH5g7KQ30Y7nMdBPqS60i=Q@mail.gmail.com>
Subject: Re: BUG: PostgreSQL 19devel throws internal opfamily error for FK
 with reordered referenced columns
To: Fredrik Widlert <fredrik.widlert@digpro.se>
Cc: Junwang Zhao <zhjwpku@gmail.com>, Matheus Alcantara <matheusssilv97@gmail.com>, 
	pgsql-bugs@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BHiwqH_gVz_V8nqCf9jjHZkUT%3DQH5g7KQ30Y7nMdBPqS60i%3DQ%40mail.gmail.com>
Precedence: bulk

On Fri, Apr 10, 2026 at 5:05=E2=80=AFPM Amit Langote <amitlangote09@gmail.c=
om> wrote:
> On Fri, Apr 10, 2026 at 4:29=E2=80=AFPM Fredrik Widlert
> <fredrik.widlert@digpro.se> wrote:
> > Thanks for the very quick fix - it's a great feeling to report a proble=
m
> > and get it fixed this quickly.
>
> Credit goes to Matheus for quickly submitting a well-written patch.
>
> > I can confirm that the fix solves not only the small reproducer but als=
o
> > the original problems I got when trying to install our (large) system
> > on PostgreSQL 19 devel for testing.
>
> Thanks for confirming that.
>
> > We actually ran into the same problem in two ways:
> > * the reordered FK with datatype mismatch (my reproducer)
> > * other reordered FKs with the same datatypes, where we instead got
> >   regular FK violations
> >
> > In case you want a reproducer for the second case as well, I've include=
d it below,
> > but perhaps it's not relevant since the patch already fixed it.
> >
> > ----
> > drop table if exists parent, child;
> >
> > create table parent (
> >      c1 integer,
> >      c2 integer,
> >      primary key (c1, c2)
> > );
> >
> > create table child (
> >      c1 integer,
> >      c2 integer,
> >      constraint child_fk foreign key (c2, c1) references parent (c2, c1=
)
> > );
> >
> > insert into parent (c1, c2) values (1, 2);
> > insert into child (c1, c2) values (1, 2);
>
> Good to know.  It's worth adding this case next to the ones Matheus's
> patch added, which the attached patch does.  Will push it shortly.

And done.

--=20
Thanks, Amit Langote