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 1wg0nI-005r2q-1j for pgsql-bugs@arkaria.postgresql.org; Sat, 04 Jul 2026 13:52:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wg0nH-00ALSC-0h for pgsql-bugs@arkaria.postgresql.org; Sat, 04 Jul 2026 13:52: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.96) (envelope-from ) id 1wfnHo-009NuG-1r for pgsql-bugs@lists.postgresql.org; Fri, 03 Jul 2026 23:27:08 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wfnHl-00000001NeC-2eJp for pgsql-bugs@lists.postgresql.org; Fri, 03 Jul 2026 23:27:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:Cc:From:To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Content-ID: Content-Description:In-Reply-To:References; bh=uXxnpvNm53poDwuRqBIZkgI3s28GxCtS7onVoMJLJyI=; b=MbRpcbSmRvTHusHCXphcVoWpNq qsKWjBR6GdNImNUyQVa3R+HdlqXduiZ4x5bc92U/QP3390LOPqrgzdJdGYAQGKFAI+NfCrN5Br+zH KLZ2v9qO94DE+WyQLzO5C+8UDGQmGzueN1Nr0n3ZkJAfjqCoK0DycA8BaWQClQY0Pql8XyK6ofb5X dK4P8W5EtAR8pQnk4lCg0fUYRfpQhRUlW9UgXCjDBb0zkxtrDYHQC7QdT8HqeYHz0SRL3k6tHyxco qVJzHEp7asCOb3imEU8c+3pYw0ufqQLvTySjIRC35gEUM4mqX9fux/Wh8Yfm/wlZbuS8exiD0XQpm UqvR9xug==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wfnHk-00AJWv-2L for pgsql-bugs@lists.postgresql.org; Fri, 03 Jul 2026 23:27:04 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wfnHj-00Azfu-0G for pgsql-bugs@lists.postgresql.org; Fri, 03 Jul 2026 23:27:03 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19543: ALTER RULE ... RENAME accepts reserved name "_RETURN" for a non-view rule; breaks a restored dump To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: adamkpickering@gmail.com Reply-To: adamkpickering@gmail.com, pgsql-bugs@lists.postgresql.org Date: Fri, 03 Jul 2026 23:26:57 +0000 Message-ID: <19543-461228e77f3b32fc@postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The following bug has been logged on the website: Bug reference: 19543 Logged by: Adam Pickering Email address: adamkpickering@gmail.com PostgreSQL version: 18.4 Operating system: Debian (using an official postgres docker image) Description: =20 PostgreSQL version Official postgres container from dockerhub (Debian 18.4-1.pgdg13+1) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit (also observed on 17.10 and current 14) Platform aarch64, Debian 13-based (official postgres:18 image), Linux 6.6, default server config. Description CREATE RULE rejects the name _RETURN for a rule that is not an ON SELECT rule. ALTER RULE ... RENAME does not: an existing ON UPDATE/INSERT/DELETE rule on an ordinary table can be renamed to _RETURN and the server accepts it. A subsequent pg_dump emits a CREATE RULE "_RETURN" ... statement the server rejects on reload, so the database can be dumped but not restored. Exact steps to reproduce (run with psql -X, no ~/.psqlrc) CREATE TABLE t (a int); CREATE RULE r AS ON UPDATE TO t DO ALSO SELECT 1; -- rejected CREATE RULE "_RETURN" AS ON UPDATE TO t DO ALSO SELECT 1; -- accepted; this is the bug ALTER RULE r ON t RENAME TO "_RETURN"; then: $ createdb fresh $ pg_dump -t t --no-owner | psql -X -d fresh -v ON_ERROR_STOP=3D1 Output I got: CREATE TABLE CREATE RULE ERROR: 42P17: non-view rule for "t" must not be named "_RETURN" LOCATION: DefineQueryRewrite, rewriteDefine.c:456 ALTER RULE The CREATE RULE "_RETURN" is rejected (expected); the ALTER RULE ... RENAME TO "_RETURN" reports ALTER RULE, i.e. it succeeds. pg_dump then produces CREATE RULE "_RETURN" AS ON UPDATE TO public.t DO SELECT 1 ..., and reloading it fails with the same 42P17 error. Output I expected: ALTER RULE ... RENAME TO "_RETURN" rejected the same way CREATE RULE rejects it, so _RETURN can only ever be a view's ON SELECT rule and any relation that dumps cleanly can be reloaded. Context The guard on CREATE RULE was added deliberately (commit by Tom Lane, released in 14.3 / 13.7 / 12.11 / 11.16 / 10.23, "Disallow rules named _RETURN that are not ON SELECT"; the in-tree comment states it "prevents accidentally or maliciously replacing a view's ON SELECT rule with some other kind of rule").