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.96) (envelope-from ) id 1wIJOO-007yBI-0V for pgsql-hackers@arkaria.postgresql.org; Thu, 30 Apr 2026 04:52:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wIJON-005wrq-10 for pgsql-hackers@arkaria.postgresql.org; Thu, 30 Apr 2026 04:52:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wIJOM-005wri-2q for pgsql-hackers@lists.postgresql.org; Thu, 30 Apr 2026 04:52:51 +0000 Received: from mail-dy1-x1341.google.com ([2607:f8b0:4864:20::1341]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wIJOK-00000003S1D-3Xnw for pgsql-hackers@postgresql.org; Thu, 30 Apr 2026 04:52:50 +0000 Received: by mail-dy1-x1341.google.com with SMTP id 5a478bee46e88-2d9916deb14so1047979eec.0 for ; Wed, 29 Apr 2026 21:52:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777524768; cv=none; d=google.com; s=arc-20240605; b=YA5PvNIRrxN3koI7m9Ndl2/9bZjTWV2cppxU0WKODSeLjyjef4EgGsz/uDUfZ1DAcc O+CGavVzdyTkpdFGL2k59i6SzgMKYVZaNF6RdJynGFQeP3Lp8adhA+K1mu7V5R8+px8r HGlTvwHL/0FlEe7y3Wq+lWSJuP2vy/XDiz/B83/gZ3LM6EEPsizpiatbVK69KKWF1q4h 5b4ufLW9cbcfznUjrOoHnIwhN8tYhP/BNyNSqYO/XEfBBIJ0Q+Y0yDplGcZiuDvPVPfu jjohG4zmoXDkrHwH554HgERojV8fgg2mOknG0203+rEMiDEx4FbdBfN+Fgsb92rYlUkq 72OA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=d0ulYEaN/e7ZyuPd4fA4AOKIgNoPHh/h192cD/W0Cdw=; fh=5i5zBCrxbexgyvr7P+Kqy8itYoFBTea2/VV4mwH9Odg=; b=UtcCJXRGyjSXa+jFlUePu2SxuPXDA/URb/Jf/KT49Xtk/UhdBwj+nqhu6kPQteEtaB vZr51uZZZCAt+x5s/F6zyelpdokrKKHu6EmTNwXrJRjug7JX285EQ4MRe8kR7LuXuJwc 6H40/8mksPb2K0PTDBmEjWEJOuMFdxN3Kd6YaZ/VxU5ROkatddkmwKo3GlRnSvS0bRY8 Dx1pt1XeilrOfNwsGE+ULmaMUsJks7MT/b47n///OfUWXLesrqnyR0C75pp6pqKhGSFa 5VQef2QjjdDOI/vkb9ofjNeY4mYi5cc2Qeb7vxOb+rMTp7iLdJZ2blqwrp+yPTvH1Fvi WUTA==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777524768; x=1778129568; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=d0ulYEaN/e7ZyuPd4fA4AOKIgNoPHh/h192cD/W0Cdw=; b=LnzEQ8KyoWW5hrh/ynSRYyXOVgsublTleNc1X/HZtAE0yp9JczG0QuMGrblk0VuXHP 9jV96BKH/DycTbxzvlJ359ojj2FbDxMLgTAD99zL6YzNjYESQWiZtXFMXYUmRqYdemFS mpo4+UBvSmueTimD2WT3rD8wh1VU/KMA1HQfdbZGV4uTNkFhJ6TWWJyJqtfQkLFhyyme yFlybY3ioEONUIUfddT9wgp3L7Jk8tCeuCrOW4veWuDmD40/o+ljS0BS6t8/oz7zgvq5 m0B05bZMuCe9DO0rP+9/5Ezfgy2qoSfZDjw7EAymhPnaKT4hobOa514yF2QdwIY03ZbO /O3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777524768; x=1778129568; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=d0ulYEaN/e7ZyuPd4fA4AOKIgNoPHh/h192cD/W0Cdw=; b=s+ntNo729uVtts2SmFZbYlFQ3UGKFa7jbdwYMf/RRStt7NLuqOzZcZBapx5IauXdEt jkW/11icruwC7aUslsjvr5gWZFq6aBGtob2IuX4K5zAe1s5E+Jh9vp4yxigf0tHwtlBl x4nE40HrKbQReWGPHGdEdnQNHF9+uSUYztjRJZNN+eSBCyfPfi7HspiemmmoJUjrhzTa ayUQH6X3YWh15/fyAsscW5qaJMf0lgo6kiaA2rIz/V1AFvg8Un+P7bJ52oYSb+vyDPIL E2cy7K6/2yq5/ErxtijfMz1vsxRul8/yET5bB1COTYhWPLT1eZKhPE9xMaKi4LiNcQGQ pdwg== X-Gm-Message-State: AOJu0YwZZkIgKqdVJY+ABrQ1M28RF5QWTar0aH7nCaOyGl7OI+ahbvVx shS1+2mm5K+JfbBahH+9miA/1+IpxU/tdARwfEENm7/d7RA57s/4ojE8zhhcXnl8UE7v2bvb9Mu RMQLE3sZLMwnk39jN8ImykO0DMJAPLmIKon6GgEU= X-Gm-Gg: AeBDietzXywwpShmfJZ+H5HFLT9PvAoVh04ARoe9i8+D/BlnUNNKXSJfRZ6Ubd8XQtO 4jXqdrGNlQxYEQxQ9DB7USXsMf5DOjl5A0ppX8ItPCv6W1lyKRpN8yw+OkdnsNqavuqxb7jvc0t ce5uS1jzWLQLOxYeTzdjk5Y4cmVkECAI9eVEYxBfuQIVHHXowcn5oGD/qRdlzUVVus4jebY1E1R wm5dWsj87b+2wziJNQTN2aMff50HGAegeEpIx1kDJjH70+1088lqydIC4Wef3a6fx1+ofqnsRK9 qU8mOMWsLTKs4ltwSQ== X-Received: by 2002:a05:7301:608b:b0:2bd:c285:2fe with SMTP id 5a478bee46e88-2ed3bef29e7mr498803eec.9.1777524768220; Wed, 29 Apr 2026 21:52:48 -0700 (PDT) MIME-Version: 1.0 References: <2B70C6CA-606B-438C-8EF2-84DCBA1C0813@gmail.com> <43c6b885.7d4a.19bd5b24501.Coremail.jinbinge@126.com> In-Reply-To: From: lakshmi Date: Thu, 30 Apr 2026 10:27:00 +0530 X-Gm-Features: AVHnY4LbCK7yjXVqjscT-lh8SgAb7FMq8n3FE8d2BNEIm5y2HvSR5OwZ8Xn8bT8 Message-ID: Subject: Re: let ALTER TABLE DROP COLUMN drop whole-row referenced object To: pgsql-hackers Cc: =?UTF-8?B?6YeR?= , Kirill Reshke , Chao Li , jian he Content-Type: multipart/alternative; boundary="00000000000063a8bd0650a63cf0" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000063a8bd0650a63cf0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I tested the latest v8-0001 patch on current master and wanted to share my observations. Before applying the patch, when dropping a column, constraints and indexes that referenced the whole row (for example, CHECK (ts =3D ROW(...)) or expressions using ts) were not removed. This left the table in an inconsistent state and resulted in errors during inserts. After applying the patch, these objects are correctly detected and removed when the column is dropped. The table remains clean, and inserts work as expected. I also tried a few additional scenarios: - DROP COLUMN with CASCADE=E2=80=94behaved as expected, no leftover object= s - normal column-level constraints =E2=80=94 still handled correctly (no re= gression) - multiple whole-row constraints =E2=80=94 all removed properly - ALTER COLUMN TYPE =E2=80=94 correctly throws an error when a whole-row constraint exists Overall, the behavior looks correct and consistent based on these tests. Thanks for working on this! lakshmi --00000000000063a8bd0650a63cf0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

I tested the latest v8-0001 patch= on current master and wanted to share my observations.

Before apply= ing the patch, when dropping a column, constraints and indexes that referen= ced the whole row (for example, CHECK (ts =3D ROW(...)) or expressions usin= g ts) were not removed. This left the table in an inconsistent state and re= sulted in errors during inserts.

After applying the patch, these obj= ects are correctly detected and removed when the column is dropped. The tab= le remains clean, and inserts work as expected.

I also tried a few a= dditional scenarios:

  • DROP COLUMN with CASCADE=E2=80=94behaved as expected, no l= eftover objects

  • normal column-level constraints= =E2=80=94 still handled correctly (no regression)

  • multiple whole-row constraints =E2=80=94 all removed properly<= /p>

  • ALTER COLUMN TYPE =E2=80=94 correctly throws an error= when a whole-row constraint exists

Overall, the behavior = looks correct and consistent based on these tests.

Thanks for worki= ng on this!

lakshmi
--00000000000063a8bd0650a63cf0--