Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lzGnM-0000qf-T9 for pgsql-hackers@arkaria.postgresql.org; Fri, 02 Jul 2021 10:53:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lzGnL-00031a-OG for pgsql-hackers@arkaria.postgresql.org; Fri, 02 Jul 2021 10:53:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lzGnL-0002zj-GD for pgsql-hackers@lists.postgresql.org; Fri, 02 Jul 2021 10:53:15 +0000 Received: from wforward1-smtp.messagingengine.com ([64.147.123.30]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lzGnI-00067j-Jf for pgsql-hackers@postgresql.org; Fri, 02 Jul 2021 10:53:14 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailforward.west.internal (Postfix) with ESMTP id DF6F11AC1033; Fri, 2 Jul 2021 06:53:10 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 02 Jul 2021 06:53:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=dLTD11R7EgM90yC29iCMyMaeQgF/MiRfSsY05rpu3 8s=; b=mwB9ZpR2B4r5AA5qrZMrL5Pif+lKcrpLpIf8zwZ0SwwnIs4SEvCMpsBxc DL7BdGT704Fua0dcewne9UkrC8NNzQ0MowA/x8R4Me0TBp2kO/WTGbMHUVDEiC1C M5nkgEz7NWIKhTuacs7Jz0oiLExJq6U+h7Cn673wxrucANDUV0HK2/CEwPtPFgtR 7dwqDLGgZU451qZgGf0kvBKEzfLOm+JHnz0FbGZILQVh1mKVZBQDzfrY3wzORwNV DO6wTWq+QfNaep53iP7EiJNkpONsmQIjTj4O3qgnw1bx3VOBODE1fyIBL+TWcYfX KtFaDNoE+8h9vFMpR2eK3NWoi+BjA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeeikedgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefheenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvg hrphhrihhsvggusgdrtghomheqnecuggftrfgrthhtvghrnhephfefleefueevuddvffeh jedtjeejgfelhfdtvdffheeludetudegfeeftdffffejnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhdrvghishgvnhhtrhgruhht segvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 2 Jul 2021 06:53:09 -0400 (EDT) Subject: Re: wrong relkind error messages To: Michael Paquier Cc: pgsql-hackers References: <01d4fd55-d4fe-5afc-446c-a7f99e043f3d@enterprisedb.com> From: Peter Eisentraut Message-ID: <84b376ef-573f-47bf-fff9-797078b7146b@enterprisedb.com> Date: Fri, 2 Jul 2021 12:53:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 02.07.21 08:25, Michael Paquier wrote: > + ereport(ERROR, > + (errcode(ERRCODE_WRONG_OBJECT_TYPE), > + errmsg("ALTER action %s cannot be performed on relation \"%s\"", > + action_str, RelationGetRelationName(rel)), > + errdetail_relkind_not_supported(rel->rd_rel->relkind))); > Perhaps the result of alter_table_type_to_string() is worth a note for > translators? ok > + case AT_DetachPartitionFinalize: > + return "DETACH PARTITION FINALIZE"; > To be exact, I think that this one should be "DETACH PARTITION > ... FINALIZE". ok > + if (relkind == RELKIND_INDEX || relkind == RELKIND_PARTITIONED_INDEX) > + ereport(ERROR, > + (errcode(ERRCODE_WRONG_OBJECT_TYPE), > + errmsg("cannot change schema of index \"%s\"", > + rv->relname), > + errhint("Change the schema of the table instead."))); > + else if (relkind == RELKIND_COMPOSITE_TYPE) > + ereport(ERROR, > + (errcode(ERRCODE_WRONG_OBJECT_TYPE), > + errmsg("cannot change schema of composite type > \"%s\"", > + rv->relname), > + errhint("Use ALTER TYPE instead."))); > I would simplify this part by removing the errhint(), and use "cannot > change schema of relation .." as error string, with a dose of > errdetail_relkind_not_supported(). I aimed for parity with the error reporting in ATExecChangeOwner() here. > + errmsg("relation \"%s\" cannot have triggers", > + RelationGetRelationName(rel)), > Better as "cannot create/rename/remove triggers on relation \"%s\"" > for the three code paths of trigger.c? > > + errmsg("relation \"%s\" cannot have rules", > [...] > + errmsg("relation \"%s\" cannot have rules", > For rewriteDefine.c, this could be "cannot create/rename rules on > relation". I had it like that, but in previous reviews some people liked it better this way. ;-) I tend to agree with that, since the error condition isn't that you can't create a rule/etc. (like, due to incorrect prerequisite state) but that there cannot be one ever.