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 1vjBpC-00AAa8-1f for pgsql-hackers@arkaria.postgresql.org; Fri, 23 Jan 2026 07:43:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vjBpA-00GbOj-0J for pgsql-hackers@arkaria.postgresql.org; Fri, 23 Jan 2026 07:43:20 +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 1vjBp9-00GbOb-2S for pgsql-hackers@lists.postgresql.org; Fri, 23 Jan 2026 07:43:20 +0000 Received: from mail-yw1-x1136.google.com ([2607:f8b0:4864:20::1136]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vjBp7-001tTA-1r for pgsql-hackers@lists.postgresql.org; Fri, 23 Jan 2026 07:43:19 +0000 Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-79427f739b0so20020627b3.3 for ; Thu, 22 Jan 2026 23:43:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769154197; cv=none; d=google.com; s=arc-20240605; b=Pi+IKvmHOKXLhpCiXN26YRl/Fvo2O31CA30bJG2/JBtMic0qUcj42INMKGvJm0Jg7g BCznDWbnmWdPFlO+oqZTLkFJ0s48iCy0VB+98wAy3GYUspavNhe7Mg+O9IKcAbrrpkmF +nvPj+fO4pBBWOkfatSn+n+y9jmtRRdjPSYGzEuyRDNdac+9v/zkYPg7ZYc6bAcjTy1c 9okbEUMtsvUPQ4IUfLLxniQqAT+rJPH25jZT59kntk/XyjOVsndbYo4uhFFvBrUroG7f FELsxaCYY9h7GSGEJEAOBynhV1E4ZSrJ7E5AlFqzBucEW16WBjv3/kVf0BzCulRsIyC5 ZH9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=sV9tH4/zcL23zIk11leeleFi+9dUx2DY84UZElPk7mk=; fh=API7pHFvHz//VzzmsjMiZjVU2agzigd09gVcY4RidXg=; b=IyMy0cJZDp4E7Vh7W/uDAKGlaIvwUNBnzL6OE6Vj4u6CLuudXhLhomoFL1AI+HQkMy d0B72TxVAq1jTCwXRWeJVGETyAAb+wyLfhaLdl5/VltRg94Cfbsv+8xB+oTpvCa22t/T t3bROPHDaDXuktoMNGF3WIdtaRJ+HN/0OUWz7RFPtossKbvv/Y/6gKYy9ljACHpL83f1 iUCWGDKsZpAseY49v3bVgbYf6lmAG1uoEKJfkaS3CWCAQq9WH8P8AllHMEBnNanmZlDi 3KdFNzT7rp12w6QKOeu08e6Co4J2ON4EWiKjVkL+QoK1wiOhz+7Q7Z32m5Q7dv5tWHT4 87IA==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=percona.com; s=google; t=1769154197; x=1769758997; 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=sV9tH4/zcL23zIk11leeleFi+9dUx2DY84UZElPk7mk=; b=AtDZo7TJbddDUYSyimfKJ7LXnMkoXnlKI3IvIpatV52Bi1cnPm1Xk3Y9FbP6V4dfJt Oz0UVka3TXBl7oKkI2MrkSBVznHIm5ZkUWf4fvODfswTR74MJ/OKwkFQKMKn/zpotbgt J5Zn/X7SiBUKXoplCAEVVcGKe4XB49ORrcEVU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769154197; x=1769758997; h=content-transfer-encoding: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=sV9tH4/zcL23zIk11leeleFi+9dUx2DY84UZElPk7mk=; b=aeUOqBnsxWgCaaHx/dy3uO3LfBr6Qxj9Nq7uDOSIqXWxl3IbNd8tqzJX4Ep8r9CHLj 9D3/pcaqPJe9JXpf4kFEbTZ7XNdMg2z4zbix5KaK5FmBBm9alpuD53kB3JqQxAxKuJxG ZvJIBp/4YCWYqJG1MyRaiWdHbnHyFPLj9x60rTM8I/TLdChRnw/7u8Sga9926GJ5KPAO 1YnYzJcQFM1aOQeWIos3C6DxQFC9V9QNUzRMLxNwgfMOIimtnm+AlGauhJ7x+tmFCH6O MvmQwdKYGqYBF0Yro9fdHH03MDsTOYmXiF5K9bMXxj8vLh97iby54Fvg+DAlnH27Hzq7 boCw== X-Gm-Message-State: AOJu0YxEerNap7n+6l/Xb0Mk2I3jNNODb9JYV9Jt2nRoT00NEknnYQsU 1OhnpFqqz4fSQN47y1/1ilZt5/bdq8Tt0jPy2M8PS0bih3CYvZnlGR/M7pREkvkIVqVJCW1WIqW RZte7jkRjDYysHFKIhwStUL4zntSQHerrlAOg6NWEw1XujMmPKH5603twgMB3NBHF7M+mxkICs0 kLyMQ2rpwkaD6O+FyVuykGtn2UcQUg/VZsvR1elvC7Df+XN+ZITecstKwg2cSkwQwi4zVeGHo71 suMK4iseMMoxWIHa8OB38OOYDn4Ig+O4HGjWbmcdtUF2b2Nd8N6oAcK+cq8mML/3GM= X-Gm-Gg: AZuq6aIWMwJHdFgz7+KSi6cU6pTockjHsZxQ9No4iFENqILwFAj/yyo4FoVODRq7x4x yMMfxg5gq7unePSIJl1EVgH37Lq2m7qiEUksSrZN31lGgvqE6L6Q0d9wqRtu1I2+ZKnFlWikits OjbmXb5Ug11EurMyIMSuhKs5TX+ibONR8O/7GEG5xAZqNANlobDRSGOEuuolG0pxMsuSjiI5Ehk 02SbZpLJuzzpWFwGZb620r/LU0Rw5ndE82MXJ/CWZsIpaupgsdyBWiVndQHyn2tS0mj4siNwrTa n4TS3G/1oYyLoumQqOAakcYv9gbRhiP08FfGTHpMBc2L3tmUSUVNEkA41PjEZEHcAA0= X-Received: by 2002:a05:690c:fd6:b0:794:668:ef12 with SMTP id 00721157ae682-79440b74196mr2273887b3.64.1769154196965; Thu, 22 Jan 2026 23:43:16 -0800 (PST) MIME-Version: 1.0 References: <07773235-2E94-478F-BEF6-38C73B0553B8@gmail.com> In-Reply-To: From: Zsolt Parragi Date: Fri, 23 Jan 2026 07:43:07 +0000 X-Gm-Features: AZwV_QhxX7lWnpU7MdkDSxiqMPJAjFEdwDcP1Ksz2Bt4LZcYhuyTJmZMhpbJClM Message-ID: Subject: Re: tablecmds: reject CLUSTER ON for partitioned tables earlier To: Chao Li Cc: Postgres hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-CLOUD-SEC-AV-Sent: true X-CLOUD-SEC-AV-Info: percona,google_mail,monitor X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello! A simple patch and generally looks good, I only have a few observations. > =E2=80=9CALTER TABLE =E2=80=A6 CLUSTER ON=E2=80=9D and "SET WITHOUT CLUST= ER" are not supported for > partitioned tables, but currently ATPrepCmd() allows them through and the= y > only fail later at execution time. Looking at the ALTER TABLE documentation, for other options there is a mention like "This form is not currently supported on partitioned tables." / "This form is not supported for partitioned tables." I don't see this mentioned for CLUSTER or INHERIT. Maybe it would be better to also mention this in the documentation? Also, there seems to be no test for partitioned NO INHERIT, since the patch changes it, it could also add a test case to verify the behavior. rg "INHERIT" | grep "cannot be performed" src/test/regress/expected/alter_table.out:ERROR: ALTER action INHERIT cannot be performed on relation "partitioned" rg "NO INHERIT" | grep "cannot be performed" # no result tablecmds.c:5202 case AT_DropInherit: /* NO INHERIT */ ATSimplePermissions(cmd->subtype, rel, - ATT_TABLE | ATT_PARTITIONED_TABLE | ATT_FOREIGN_TABLE); + ATT_TABLE | ATT_FOREIGN_TABLE); /* This command never recurses */ + ATPrepChangeInherit(rel); /* No command-specific prep needed */ That last comment seems to be a leftover, it's no longer true with this cha= nge. tablecmds.c:17289 trailing whitespace (in the empty line) /* + * ALTER TABLE INHERIT + * + * Add a parent to the child's parents. This verifies that all the columns= and + * check constraints of the parent appear in the child and that they have = the + * same data types and expressions. + * * Return the address of the new parent relation. */ tablecmds.c:17860 - this check in ATExecDropInherit is now redundant, since we already have it in ATPrepChangeInherit > Before the patch: > ``` > evantest=3D# ALTER TABLE p_test CLUSTER ON idx_p_test_id; > ERROR: cannot mark index clustered in partitioned table Can we still reach the original error in mark_index_clustered somehow? I don't see any examples in the test suite, or execution paths when I have looked at the code, and it can be confusing to see a different error code/message there.