Feedback-ID: ie3de48e3:Fastmail
Date: Fri, 8 May 2026 19:20:04 +0200
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: Jim Jones <jim.jones@uni-muenster.de>
Cc: Andrew Dunstan <andrew@dunslane.net>, Chao Li <li.evan.chao@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Fix wrong error message from pg_get_tablespace_ddl()
Message-ID: <af4YmulGI3pq2Rm0@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <edcd87ec-e91d-44f8-a8a3-d19c786b2712@uni-muenster.de>
Archived-At: 
 <https://www.postgresql.org/message-id/af4YmulGI3pq2Rm0%40alvherre.pgsql>
Precedence: bulk

On 2026-May-08, Jim Jones wrote:

> It depends on what we expect from the error message. If its purpose is
> simply to tell the user "you can't access this object," the current message
> is totally fine. If, however, the goal is to show the error's root cause, it
> could be a bit misleading.

Hmm, the idea in my mind was that if SELECT from the catalog is
revoked, but the user does have a grant on the tablespace that lets them
read the DDL, then they should be able to obtain the CREATE statement
for it even though they cannot read the properties from the catalog
directly.  The current coding does not seem to do that, but instead
it refuses to produce the DDL.  Is this really what we want?

Although tablespaces may be special in that only superusers can "own"
them anyway.

TBH I'm undecided about how this should work.  If somebody has
ACL_CREATE on a certain tablespace, should she be able to know what the
spcoptions are, for instance?  What about a database owner whose default
tablespace is that one?  Maybe we'd hide the location unless superuser,
and show the rest ...?

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"This is a foot just waiting to be shot"                (Andrew Dunstan)