Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jGUug-0005rM-VM for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Mar 2020 21:47:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jGUuf-0001J5-O9 for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Mar 2020 21:47:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jGUuf-0001Iy-9z for pgsql-hackers@lists.postgresql.org; Mon, 23 Mar 2020 21:47:13 +0000 Received: from mail-qk1-x744.google.com ([2607:f8b0:4864:20::744]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jGUua-0004su-Ur for pgsql-hackers@postgresql.org; Mon, 23 Mar 2020 21:47:12 +0000 Received: by mail-qk1-x744.google.com with SMTP id x3so5641570qki.4 for ; Mon, 23 Mar 2020 14:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2qybgZCFjz+az7/Z11xJkMN55c/8T4Tbs3pUIbTrN8U=; b=JHP5y85oTqqviAYsaPoZmOz6mZ6W4bha+T0k0dZLtUx1e6UyOVxrwGWNcUX+fTV1Rt rmULLUn0SEvS/c2LcHq7UlJe1Ps6VvXc9lPEYGlEtSZn0leEhs2zNt0z58UT2lGx+x57 EG59B6a3nQuF2B6M08jdj1DaEVyQih5mXwBf/jzzcVnLPdhAVnOV6nlkrJTgd+E8P2RI pOVE7/575vBxJ0QxuLysIS1oqEr0xiO/MKd+irEINqpdkVv4o1LJWGaG+eVIl3cyHSOy B4Vc9OlMO35yu+ysBI8FlDyUSnRbr1ejYA37YbcrLb+mYIQdp+QN3J9V9IUj9GRt5p70 aeaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=2qybgZCFjz+az7/Z11xJkMN55c/8T4Tbs3pUIbTrN8U=; b=R7I04N6dnh9kPOLVhDIdj2qCKbvOkNDOhp9aZNBN3wgnQI90k9qP8wx2OYmSFiIccS blFvQG3SZTRbrwW7XPQgZj3eYiSwN1ysRygnaBqcFQdRlur1jLvOfQ80hmtAtOUj7lDn mymBsBr4UKLX0XVY/jTBp5ywXcbhb8sh/hLam4XdjTIo0T8UkHX/1FC4UW83/1ih8OGY y3A9V/XkadaOLPMYvxcG/FLTFKSgXd+r6xz5pbF0M7hHYLCul/MuRlppJafNcPYIWS/R jyn21EszXMtWMFF9Vg0LRMmW7TYtiTzhHzCUqXoZkmF1KJbPMlxg3Kkh6CDUNpAkqX4M B27A== X-Gm-Message-State: ANhLgQ3wdW1p8v+Pwa6QokfLTMgUtXnGaIgYwnfG6gJWO17adkxkNAro 6QBz7WHWk4R+UDuLhkHR475EBQ== X-Google-Smtp-Source: ADFU+vucFFIw1akVNBdLi2ws/RAG5ojVCn/0+2YlXEOL7cOLs9yoxBvBw1xFNlcX6n3LMotowWazLA== X-Received: by 2002:ae9:e88c:: with SMTP id a134mr23141005qkg.183.1585000027087; Mon, 23 Mar 2020 14:47:07 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id 207sm12158107qkf.69.2020.03.23.14.47.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2020 14:47:06 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id B404F800E5C; Mon, 23 Mar 2020 16:47:04 -0500 (CDT) Date: Mon, 23 Mar 2020 16:47:04 -0500 From: Justin Pryzby To: Robert Haas Cc: Alvaro Herrera , pgsql-hackers@postgresql.org Subject: Re: ALTER INDEX fails on partitioned index Message-ID: <20200323214704.GM2563@telsasoft.com> References: <20190206173212.GA23770@alvherre.pgsql> <201901071923.7r2xflxvncly@alvherre.pgsql> <20191227035157.GD12890@telsasoft.com> <20200227232513.GE29456@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200227232513.GE29456@telsasoft.com> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Feb 27, 2020 at 09:11:14PM -0300, Alvaro Herrera wrote: > On 2020-Feb-27, Justin Pryzby wrote: > > The attached allows CREATE/ALTER to specify reloptions on a partitioned table > > which are used as defaults for future children. > > > > I think that's a desirable behavior, same as for tablespaces. Michael > > mentioned that ALTER INDEX ONLY doesn't exist, but that's only an issue if > > ALTER acts recursively, which isn't the case here. > > I think ALTER not acting recursively is a bug that we would do well not > to propagate any further. Enough effort we have to spend trying to fix > that already. Let's add ALTER .. ONLY if needed. I was modeling after the behavior for tablespaces, and didn't realize that non-recursive alter was considered discouraged. On Thu, Feb 27, 2020 at 05:25:13PM -0600, Justin Pryzby wrote: > The first patch makes a prettier message, per Robert's suggestion. Is there any interest in this one ? > From e5bb363f514d768a4f540d9c82ad5745944b1486 Mon Sep 17 00:00:00 2001 > From: Justin Pryzby > Date: Mon, 30 Dec 2019 09:31:03 -0600 > Subject: [PATCH v2 1/2] More specific error message when failing to alter a > partitioned index.. > > "..is not an index" is deemed to be unfriendly > > https://www.postgresql.org/message-id/CA%2BTgmobq8_-DS7qDEmMi-4ARP1_0bkgFEjYfiK97L2eXq%2BQ%2Bnw%40mail.gmail.com > --- > src/backend/commands/tablecmds.c | 23 +++++++++++++++++------ > 1 file changed, 17 insertions(+), 6 deletions(-) > > diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c > index b7c8d66..1b271af 100644 > --- a/src/backend/commands/tablecmds.c > +++ b/src/backend/commands/tablecmds.c > @@ -366,7 +366,7 @@ static void ATRewriteTables(AlterTableStmt *parsetree, > static void ATRewriteTable(AlteredTableInfo *tab, Oid OIDNewHeap, LOCKMODE lockmode); > static AlteredTableInfo *ATGetQueueEntry(List **wqueue, Relation rel); > static void ATSimplePermissions(Relation rel, int allowed_targets); > -static void ATWrongRelkindError(Relation rel, int allowed_targets); > +static void ATWrongRelkindError(Relation rel, int allowed_targets, int actual_target); > static void ATSimpleRecursion(List **wqueue, Relation rel, > AlterTableCmd *cmd, bool recurse, LOCKMODE lockmode, > AlterTableUtilityContext *context); > @@ -5458,7 +5458,7 @@ ATSimplePermissions(Relation rel, int allowed_targets) > > /* Wrong target type? */ > if ((actual_target & allowed_targets) == 0) > - ATWrongRelkindError(rel, allowed_targets); > + ATWrongRelkindError(rel, allowed_targets, actual_target); > > /* Permissions checks */ > if (!pg_class_ownercheck(RelationGetRelid(rel), GetUserId())) > @@ -5479,7 +5479,7 @@ ATSimplePermissions(Relation rel, int allowed_targets) > * type. > */ > static void > -ATWrongRelkindError(Relation rel, int allowed_targets) > +ATWrongRelkindError(Relation rel, int allowed_targets, int actual_target) > { > char *msg; > > @@ -5527,9 +5527,20 @@ ATWrongRelkindError(Relation rel, int allowed_targets) > break; > } > > - ereport(ERROR, > - (errcode(ERRCODE_WRONG_OBJECT_TYPE), > - errmsg(msg, RelationGetRelationName(rel)))); > + if (actual_target == ATT_PARTITIONED_INDEX && > + (allowed_targets&ATT_INDEX) && > + !(allowed_targets&ATT_PARTITIONED_INDEX)) > + /* Add a special errhint for this case, since "is not an index" message is unfriendly */ > + ereport(ERROR, > + (errcode(ERRCODE_WRONG_OBJECT_TYPE), > + errmsg(msg, RelationGetRelationName(rel)), > + // errhint("\"%s\" is a partitioned index", RelationGetRelationName(rel)))); > + errhint("operation is not supported on partitioned indexes"))); > + else > + ereport(ERROR, > + (errcode(ERRCODE_WRONG_OBJECT_TYPE), > + errmsg(msg, RelationGetRelationName(rel)))); > + > } > > /* > -- > 2.7.4 > -- Justin