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.94.2) (envelope-from ) id 1ue2j6-004Ktc-3j for pgsql-bugs@arkaria.postgresql.org; Tue, 22 Jul 2025 02:27:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1ue2j5-004VIl-2m for pgsql-bugs@arkaria.postgresql.org; Tue, 22 Jul 2025 02:27:31 +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.94.2) (envelope-from ) id 1ue2j4-004VIW-Pk for pgsql-bugs@lists.postgresql.org; Tue, 22 Jul 2025 02:27:31 +0000 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ue2j2-0007nq-35 for pgsql-bugs@lists.postgresql.org; Tue, 22 Jul 2025 02:27:30 +0000 Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-6070293103cso8021294a12.0 for ; Mon, 21 Jul 2025 19:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec.at; s=google; t=1753151245; x=1753756045; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=Qw+1N3vTJvKR4WVcg9td4o97xj9hxcGf76Meljlp3AY=; b=oKVl9yS63wOdroNO/AUQ86BZvG6QZplgpkflUsSTkniGjVKqp3jE1/d9PzBkkHYZZ9 nSs0Wqd9WlTHBgRc7vTA0LYYY+DZBKq2SdfxnUC/d0vQ96oQc3TthxkR088UDBtjgJHu iK+Li1qnnP4uRyRWs1mGcL877Z8I64Xj/Z5v20sUs2MBBjiNwIXcQ3OnBdu48h5zMy4j DxBYMSx292n9omLIdoaRR4AmJs9VqF/9R+wcb/LPu/jAxlmiqW4HTNHNeQN95gcWw54A BKNlMdg2S+GhxpQAm7ludVD05ihRHSzJTatDChcS3gMnnZvgDFCVY/yQe4WPgoaPu1HK AEug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753151245; x=1753756045; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Qw+1N3vTJvKR4WVcg9td4o97xj9hxcGf76Meljlp3AY=; b=BeOVxo+YsNzo4WMH4hlX0VLgUoAoQKFTBKOuVvBIZnS8Bk5aP5iguYIYMWe9iRLKA5 Pi7yWb6C953zWRJEjP837y1uYaZoooCad1/w6pcI5H2X9IsZy46hkLiH7w//cUoEDN/2 wr99+4l+6VQ2VY4wN9WERmv9O9QYIoR2ejnmAJx9r9AUsMIv+bIj1zzzqlIcFjo6Amwe vCqh9dg2Qdv2VeFLRd0BHXj5WP/6oRJtXyomIPMGTtdJvVhkoqwI7LkUU94Bj0bLmrg4 t7bNkSfUA6l6J9e9eKMSSJyHVeuGlOxuLMBaVCRZw5AP04gse0KkFJOVDaPu2D8Vx50E TJ9Q== X-Forwarded-Encrypted: i=1; AJvYcCX/HEvIY4K5jSrSg0e9s3QY3Piw3d+ozEyM5XNqDcNluDbzmuWFo7HeLmw4AyjzGD352UCjGozJ9BW1@lists.postgresql.org X-Gm-Message-State: AOJu0YyzwZTEM6J18WH0lpOCGKZcaKSDW2c9IoWYPDXpJqDQZ02YoAu/ +ldu/aE+mBUcUyQ95wEkNSBRkPNe/OAe1pSVqaCJzj0zTEzbTanyvKVuwhPr1eAi0K0= X-Gm-Gg: ASbGncsQFfth40XigJbRtmLSJth6QYB7GDUvVA+JyLLqxT5qUZNgyEgQxRDHhPDCui5 PwoNAEq6ErrXMx6Z4Bse1Ud3NJGI7XBTDcndY1EVFlH74fo7wVphaRAHak2ArqEEBXWOgV845m7 swg+CdhBQRQf6VrUEhphwW2C2PnbAEPdAJfoc0lOSAWhFSq855lLr4r1dlAykaYRaUfaG7PUHiO Hx3U5B8itjP2hram9yGyo0B0LQXGOrqaMNRZAWZ3s6YWoDBwLRExsMrVWIO9wjT1WVQhYCosfo5 sot82FgjdzQxXVoK8blvnPcgZiKWnNC+QR6YDUzE4PGacng1FPYCs7K9soEdtqAZl4WlWGQ4phz ZQrhSMZLg5doUvwsECZn/0eDPDr+w1voTXGq1qFEu8MeHv0lgJpgE X-Google-Smtp-Source: AGHT+IEBHkqp5Mn6rASB4IoTRkeOKOcHj19QOTUZ0gknwK2gKeqENslod3epnz8quv6sg1h5JijyZg== X-Received: by 2002:a05:6402:1941:b0:608:155c:bf81 with SMTP id 4fb4d7f45d1cf-61285bf5d4emr20048618a12.31.1753151245187; Mon, 21 Jul 2025 19:27:25 -0700 (PDT) Received: from laurenz.albe-K4N0CV00F97414D ([2001:871:255:52d3:3ac8:61ab:b634:342]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-612c8f33964sm6196834a12.18.2025.07.21.19.27.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Jul 2025 19:27:24 -0700 (PDT) Message-ID: <803ddef427b9016be04af9320925e9570d3fcc06.camel@cybertec.at> Subject: Re: BUG #18964: `ALTER DATABASE ... RESET ...` fails to reset extension parameters that no longer exist From: Laurenz Albe To: Nathan Bossart , Tom Lane Cc: mert@futo.org, pgsql-bugs@lists.postgresql.org Date: Tue, 22 Jul 2025 04:27:24 +0200 In-Reply-To: References: <18964-ba09dea8c98fccd6@postgresql.org> <2474668.1750451081@sss.pgh.pa.us> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-1.fc42) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, 2025-06-25 at 11:06 -0500, Nathan Bossart wrote: > Here is a tidied-up version of the patch. It's still quite fragile, but > AFAICT to do any better we'd need to return more context from > find_option(), and I don't think we can change that one on the > back-branches since it's exported. I assume we don't want find_option() = to > create a placeholder in this case, either. I'll continue to look around > for a better solution... I tested your patch, and it works as expected for ALTER DATABASE ... RESET ALTER ROLE ... RESET ALTER ROLE ... IN DATABASE ... RESET There is still one piece missing in my opinion: ALTER SYSTEM RESET testext.swap_limit; ERROR: invalid configuration parameter name "testext.swap_limit" DETAIL: "testext" is a reserved prefix. I think that this case should work like the others. I'd like to see regression tests for this, but I am not sure how to best devise them. One idea would be to stick them into the regression tests of some contrib module, even though it is not the perfect place. Perhaps a sequence like this: DO $$BEGIN EXECUTE format( 'ALTER DATABASE %I SET pg_trgm.somevar =3D 42', current_catalog); END$$; LOAD 'pg_trgm'; WARNING: invalid configuration parameter name "pg_trgm.somevar", removin= g it DETAIL: "pg_trgm" is now a reserved prefix. DO $$BEGIN EXECUTE format( 'ALTER DATABASE %I RESET pg_trgm.somevar', current_catalog); END$$; \drds > If we wanted to open up RESET in this case to everyone with suitable > privileges on the target DB and/or role (as proposed by Tom upthread [0])= , > I think we'd just need to replace the "return false;" under find_option() > to "return reset_custom;". >=20 > [0] https://postgr.es/m/2474668.1750451081%40sss.pgh.pa.us I have no strong opinion about that. I'd say it is good enough to allow superusers to reset such parameters. Yours, Laurenz Albe