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 1paD0J-0006G0-Nd for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Mar 2023 09:56:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1paD0I-0002tV-DX for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Mar 2023 09:56:06 +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 1paD0H-0002tM-H1 for pgsql-hackers@lists.postgresql.org; Thu, 09 Mar 2023 09:56:06 +0000 Received: from new2-smtp.messagingengine.com ([66.111.4.224]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1paD0A-0003od-5S for pgsql-hackers@postgresql.org; Thu, 09 Mar 2023 09:56:04 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 109F8581FAC; Thu, 9 Mar 2023 04:55:57 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 09 Mar 2023 04:55:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1678355757; x=1678362957; bh=VdSIP8Cz8D1BkpTGHoKpBN0UoqF3Num2Uou wrzg/RjQ=; b=mvhSmWpwn4bRo4bsox97tIf9Dm+fwjFWc+JIlZS7sPih1Fbhc+Z mwrS4B0kF82I1GRO7ieQ6vlVAiMuLP+UDQauLuEd9mRUxj57qrZo8l83qbZJtXJX cUQBsTUVZjYQHcgEL1+l3JKndzXhoJncWqroXsN5WpNxataBPTAjPW3teKjv1/uu SHAOQwnVyswE0Bh/3qTnvGO2AfWfIUUgmSM8qA1dYnkadULXTCZohJ2Eu7ZNMP7U u70F6xMxjKwzpME/RIFMpulOqASAuC95iW0XI249z4sUXH0ZAGZYFIzd2EQhXkFb izieP567hh7i2GBrTgixtAEvyAdIKGBJRXA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdduiedgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpefrvght vghrucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgvihhsvghnthhrrghuthesvghnth gvrhhprhhishgvuggsrdgtohhmqeenucggtffrrghtthgvrhhnpefhjeduueelfeehuedt udefteejveegieeiueejueehfeektddtueeiieeitefhveenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvihhsvghnthhrrghu thesvghnthgvrhhprhhishgvuggsrdgtohhm X-ME-Proxy: Feedback-ID: i131946ab:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 9 Mar 2023 04:55:55 -0500 (EST) Message-ID: Date: Thu, 9 Mar 2023 10:55:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: improving user.c error messages Content-Language: en-US To: Nathan Bossart Cc: Alvaro Herrera , Tom Lane , Robert Haas , "pgsql-hackers@postgresql.org" References: <20230127000936.GA1998073@nathanxps13> <20230127183119.e5jtyh4g2md57ctb@alvherre.pgsql> <20230127231507.GA2221340@nathanxps13> <20230207201009.GA450353@nathanxps13> <20230220190210.GA3481922@nathanxps13> <20230220225852.GA3940888@nathanxps13> From: Peter Eisentraut In-Reply-To: <20230220225852.GA3940888@nathanxps13> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 20.02.23 23:58, Nathan Bossart wrote: >>> Similarly -- this is an existing issue but we might as well look at it -- in >>> something like >>> >>> must be superuser or a role with privileges of the >>> pg_write_server_files role >>> >>> the phrase "a role with the privileges of that other role" seems ambiguous. >>> Doesn't it really mean you must be a member of that role? >> >> Membership alone is not sufficient. You must also inherit the privileges >> of the role via the INHERIT option. I thought about making this something >> like >> >> must have the INHERIT option on role %s >> >> but I'm not sure that's accurate either. That wording makes it sound lіke >> you need to be granted membership to the role directly WITH INHERIT OPTION, >> but what you really need is membership, direct or indirect, with an INHERIT >> chain up to the role in question. However, it looks like "must have the >> ADMIN option on role %s" is used to mean something similar, so perhaps I am >> overthinking it. > > For now, I've reworded these as "must inherit privileges of". I don't have a good mental model of all this role inheritance, personally, but I fear that this change makes the messages more jargony and less clear. Maybe the original wording was good enough. A couple of other thoughts: "admin option" is sort of a natural language term, I think, so we don't need to parametrize it as "%s option". Also, there are no other "options" in this context, I think. A general thought: It seems we currently don't have any error messages that address the user like "You must do this". Do we want to go there? Should we try for a more impersonal wording like "You must have the %s attribute to create roles." "Current user must have the %s attribute to create roles." "%s attribute is required to create roles." By the way, I'm not sure what the separation between 0001 and 0002 is supposed to be.