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 1roywo-004RGN-1A for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Mar 2024 05:02:06 +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 1roywm-00B6BO-Em for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Mar 2024 05:02:04 +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 1roywm-00B6BG-5J for pgsql-hackers@lists.postgresql.org; Tue, 26 Mar 2024 05:02:04 +0000 Received: from mail-vs1-xe36.google.com ([2607:f8b0:4864:20::e36]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1roywi-006Wjx-Pb for pgsql-hackers@lists.postgresql.org; Tue, 26 Mar 2024 05:02:03 +0000 Received: by mail-vs1-xe36.google.com with SMTP id ada2fe7eead31-476794adf30so2020273137.1 for ; Mon, 25 Mar 2024 22:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711429319; x=1712034119; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+WfvOLV/NArUOnFag+oDy0HhTos6Y0cz1QFwTuJyJ94=; b=Zn6mXq4np4/ZrvZNKWl7iyguyjd7BlHiJQ+h7kFWzvfGuZ3Ytd8TC+spd15FzAYytL lqxMS91kr2A3Yyv3HuyHW5yFj+SNbFboYqtSKU4k8uokIEgdm40vvpxVs3+ifjjFkqu7 mhXCAdoY/yHpsZW9xfKcSt4TYgitu85GqyPfyLbKZ+F2QPb6toctg6pZZHIJjwQi0Bw4 BNO0RUbtM8PyYb1RFIW2CKGA6P0+Lf+iu/KIatlk7IJmhzEsu0L+3fRyWgCb9duXy5FH ebCdnC5VxAdZHS4vZJ7NM3MHmMzzPdjYh11Rnclug2mvTKMrAcQNvfu0RXzqrTTZUhV/ rrcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711429319; x=1712034119; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+WfvOLV/NArUOnFag+oDy0HhTos6Y0cz1QFwTuJyJ94=; b=wLq06g0zK+olpkwJaBw7pVQwMFZhh7sIIiHBb7QHrCCdDNQcadxvb343ba1Hj8vXJa qbJG3i/7P12ZXV4TtKFkjJpNqAcbT8eh3TwFGj5i1VRhndDk7SsKOY7sqtdXmOQgzHRv hklVXfs1eYBF3RtytBTWlW2kCYcRFsFXUBFDdPoYmPf9LkbP7YBvKjTal29LVAeZTY7I wZ9BIw6D5J4z33CZBFQD8BlXwfMSLdkPepJnQv8k1YYlfxt6mcRblXWdfSh1Mqtczlxn ggyslnDEzDa/Pynr2f6qX96qKbSVnfTjrHVdy1kkoKai+nR132jsHBpoOOzVxaZJL2pv NlRA== X-Gm-Message-State: AOJu0YxU4jNHO6L89WWt0OO9TFmrydi7q4SfsaGEhEVXxAZ0HhoD544/ MiSE6oERvWNlU/cssGGBlwACbMEX0ZUHE9hedl8HNoF7LlQ7fHS9Rn+d5oOgermb8mDFDT7NGme Pg25zNA62wRQo14t42QT8D3r6j0RqHtIkxYg= X-Google-Smtp-Source: AGHT+IE3a985+68rAAca3eKBuVJPPafC1R8zLeoUfDT1/l3Jaa+dXk0AkFT/0XWETT7ffMV8LlLJczv/+sAFW2DeuLs= X-Received: by 2002:a05:6102:21a7:b0:476:ddd4:b168 with SMTP id i7-20020a05610221a700b00476ddd4b168mr7552718vsb.20.1711429319071; Mon, 25 Mar 2024 22:01:59 -0700 (PDT) MIME-Version: 1.0 References: <78d824e0-b21e-480d-a252-e4b84bc2c24b@illuminatedcomputing.com> <69f0a887-a4ed-49cf-9d63-923891006658@illuminatedcomputing.com> In-Reply-To: <69f0a887-a4ed-49cf-9d63-923891006658@illuminatedcomputing.com> From: jian he Date: Tue, 26 Mar 2024 13:00:00 +0800 Message-ID: Subject: Re: altering a column's collation leaves an invalid foreign key To: Paul Jungwirth Cc: PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Mar 25, 2024 at 2:47=E2=80=AFPM Paul Jungwirth wrote: > > On 3/23/24 10:04, Paul Jungwirth wrote: > > Perhaps if the previous collation was nondeterministic we should force = a re-check. > > Here is a patch implementing this. It was a bit more fuss than I expected= , so maybe someone has a > better way. > + /* test follows the one in ri_FetchConstraintInfo() */ + if (ARR_NDIM(arr) !=3D 1 || + ARR_HASNULL(arr) || + ARR_ELEMTYPE(arr) !=3D INT2OID) + elog(ERROR, "conkey is not a 1-D smallint array"); + attarr =3D (AttrNumber *) ARR_DATA_PTR(arr); + + /* stash a List of the collation Oids in our Constraint node */ + for (i =3D 0; i < numkeys; i++) + con->old_collations =3D lappend_oid(con->old_collations, + list_nth_oid(changedCollationOids, attarr[i] - 1)); I don't understand the "ri_FetchConstraintInfo" comment. +static void +RememberCollationForRebuilding(AttrNumber attnum, AlteredTableInfo *tab) +{ + Oid typid; + int32 typmod; + Oid collid; + ListCell *lc; + + /* Fill in the list with InvalidOid if this is our first visit */ + if (tab->changedCollationOids =3D=3D NIL) + { + int len =3D RelationGetNumberOfAttributes(tab->rel); + int i; + + for (i =3D 0; i < len; i++) + tab->changedCollationOids =3D lappend_oid(tab->changedCollationOids, + InvalidOid); + } + + get_atttypetypmodcoll(RelationGetRelid(tab->rel), attnum, + &typid, &typmod, &collid); + + lc =3D list_nth_cell(tab->changedCollationOids, attnum - 1); + lfirst_oid(lc) =3D collid; +} do we need to check if `collid` is a valid collation? like: if (!OidIsValid(collid)) { lc =3D list_nth_cell(tab->changedCollationOids, attnum - 1); lfirst_oid(lc) =3D collid; }