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 1wM23V-002BTE-29 for pgsql-hackers@arkaria.postgresql.org; Sun, 10 May 2026 11:10:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wM23U-00EloU-1d for pgsql-hackers@arkaria.postgresql.org; Sun, 10 May 2026 11:10:40 +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 1wM23U-00EloD-0Y for pgsql-hackers@lists.postgresql.org; Sun, 10 May 2026 11:10:40 +0000 Received: from udcm-wwu2.uni-muenster.de ([128.176.118.28]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wM23Q-000000017Fs-49GP for pgsql-hackers@lists.postgresql.org; Sun, 10 May 2026 11:10:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-muenster.de; i=@uni-muenster.de; q=dns/txt; s=uniout; t=1778411438; x=1809947438; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=GHOaPx9DJMrQZUM0HwMFLydxIk/XoYvHqJsjS4+ORbY=; b=ZWnyHBdQzumlQkSD4NIAcdlXmQWdRwfhY7+sEJzAprSC8r21yfvq+jDw n3B3kQjRtzaxtxjGXsvgS9UxA0ckH+NjLvMBr3yJd6H9qZJVLwUlc46Bu RlgMAjiNBGbzue7a/2CI0T7h+Y2gqnzJDkilUOBTEAqxuPYOfYGdIT17X Ffg+lpYWqzcHn/NVdBoat4EEiQ06L9fXWZkXyHo2gcaobrIY0BF+oIqZL pSeqH+OTYd3fhWhawrIet32Q0b4nTBlo73jkyNYZbwE6SZBQ8Jp6q79xm P7JCOB6cGgpd0k+ybX40bHVsqAGHn5XOYUW2U8nZOOEWatsxhynup9cWc w==; X-CSE-ConnectionGUID: C8RRsAqBRPqnIfIiCMCl1g== X-CSE-MsgGUID: tdp+fFDSQLeVrgxS3mej8Q== X-IronPort-AV: E=Sophos;i="6.23,227,1770591600"; d="scan'208";a="393651588" Received: from secmail.uni-muenster.de ([128.176.118.4]) by UDCM-RELAY2.UNI-MUENSTER.DE with ESMTP; 10 May 2026 13:10:34 +0200 Received: from [192.168.178.49] (dynamic-093-131-154-187.93.131.pool.telefonica.de [93.131.154.187]) by SECMAIL.UNI-MUENSTER.DE (Postfix) with ESMTPSA id 2D8DD20ADF02; Sun, 10 May 2026 13:10:33 +0200 (CEST) Message-ID: <560b391a-2b3a-4009-a90b-b5e5863aa89d@uni-muenster.de> Date: Sun, 10 May 2026 13:10:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Fix wrong error message from pg_get_tablespace_ddl() To: Chao Li , =?UTF-8?Q?=C3=81lvaro_Herrera?= , Andrew Dunstan Cc: PostgreSQL Hackers References: <4B28CBF6-7470-456A-A635-62FE28067AEE@gmail.com> Content-Language: en-US, de-DE From: Jim Jones In-Reply-To: <4B28CBF6-7470-456A-A635-62FE28067AEE@gmail.com> 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 Hi Chao On 09/05/2026 04:01, Chao Li wrote: > Álvaro seems to bring the question to a deeper level, and I feel that might be worth a dedicated discussion. For example, I am not sure ACL_CREATE on the tablespace is enough to imply visibility of the tablespace DDL. My understanding is that CREATE on a tablespace allows the user to create objects within that tablespace, but it does not necessarily mean the user is allowed to inspect the definition of the tablespace itself. Yeah, this is a good point. I don't have a strong opinion about it, but I'd be inclined to simply deny access to the DDL if the user does not have enough privileges -- at least I wouldn't mind seeing an error message in my logs :) > How about keeping the scope of this patch narrow, as only adding a hint to guide users on how to fix the error if they really need to view the DDL of the tablespace? I will start a separate thread for the discussion of the access-checking model. > > The attached v2 keeps the original error message and adds a hint. I took Jim’s comment about avoiding hardcoding "pg_tablespace”. And I also added a hint in pg_get_role_ddl_internal. With v2, the messages are like: > ``` > evantest=> select * from pg_get_tablespace_ddl('ts1'); > ERROR: permission denied for tablespace "ts1" > HINT: Grant SELECT on catalog "pg_tablespace" to read tablespace properties. I'm not sure that telling unprivileged users to grant themselves access to pg_tablespace is an improvement -- IMO, a HINT here is supposed to be actionable. Perhaps a DETAIL would be a better fit, e.g. "DETAIL: The function requires SELECT privilege on catalog "pg_tablespace"." On top of that, I'm also not sure that replacing the aclcheck_error with an ereport just for the hint/detail is an option, since aclcheck_error is supposed to provide "Standardized reporting of aclcheck permissions failures." (from the aclcheck_error header comment) Thanks! Best, Jim