Re: ALTER DATABASE RESET with unexistent guc doesn't report an error - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ALTER DATABASE RESET with unexistent guc doesn't report an error
Date
Msg-id 1791672.1757607520@sss.pgh.pa.us
Whole thread Raw
In response to Re: ALTER DATABASE RESET with unexistent guc doesn't report an error  (Álvaro Herrera <alvherre@kurilemu.de>)
List pgsql-hackers
=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> On 2025-Sep-11, Kirill Reshke wrote:
>> I think we can remove "support" for ALTER DATABASE RESET TABLESPACE.

> What about ALTER USER RESET TABLESPACE?

Yeah, I think you're right.  The complaint is fundamentally that
these two cases behave differently:

regression=# ALTER DATABASE regression RESET bogus;
ERROR:  unrecognized configuration parameter "bogus"
regression=# ALTER DATABASE postgres RESET bogus;
ALTER DATABASE

the unobvious-to-the-user reason being that "regression" has a
pg_db_role_setting entry and "postgres" does not.  But there's
also no error for

regression=# ALTER USER postgres RESET bogus;
ALTER ROLE

and by the same logic there should be.  I think though that
the proposed patch addresses both cases.

Looking at the patch, the delta in database.out raises
another question:

 ALTER DATABASE regression_tbd RENAME TO regression_utf8;
 ALTER DATABASE regression_utf8 SET TABLESPACE regress_tblspace;
 ALTER DATABASE regression_utf8 RESET TABLESPACE;
+ERROR:  unrecognized configuration parameter "tablespace"
 ALTER DATABASE regression_utf8 CONNECTION_LIMIT 123;

The author of this bit of test script evidently thought that
ALTER ... RESET TABLESPACE is the inverse of ALTER ... SET TABLESPACE,
and what we are seeing is that it is not.  That may be a bug in
itself, but it's not what Vitaly is on about, IIUC.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Making type Datum be 8 bytes everywhere
Next
From: Ranier Vilela
Date:
Subject: Re: PgStat_HashKey padding issue when passed by reference