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 1wX47Q-00327x-0C for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jun 2026 21:36:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wX47O-008OZY-2S for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jun 2026 21:36:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wX47O-008OZP-1C for pgsql-hackers@lists.postgresql.org; Tue, 09 Jun 2026 21:36:18 +0000 Received: from mail-yx1-xb134.google.com ([2607:f8b0:4864:20::b134]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wX47L-00000002Dr0-3w7i for pgsql-hackers@lists.postgresql.org; Tue, 09 Jun 2026 21:36:18 +0000 Received: by mail-yx1-xb134.google.com with SMTP id 956f58d0204a3-6603246b66dso6130628d50.1 for ; Tue, 09 Jun 2026 14:36:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781040974; cv=none; d=google.com; s=arc-20240605; b=c71AGE2wEZt7Lo43mVu/XZdND2CDk++w6Q0Gv2zHEfdq9HLRKlBu1zpRvE1unVaHQj Yb7dwMHoTH9M/zYTUUwSQzeLKYFUss6nhWQX06h7MC0V+MDHSrtTSr+z7YKv97jxZq/L aHRaIz3hOPJJsCW4kFAl5uJa+pNVEQZxEAAaj4mL19uuCal7hVOS24n99bocWTJOtQtt ZM+SIa7vEc5ie56TqIbacdClO+ChRiS8HxcZy5kS62IIUQSC9vm7cvXeNACDIXlbNPFg B4Q1ivStKQIwh2Llr1fCI0/XbM+D+AjZLg80z3uugcGFc4xvG5gphj+EWKWxE7QUNLq0 8iHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :dkim-signature; bh=tIwa0VCHWpormTDLeTLZE0QVPs9muASNPB5rjC0Lukk=; fh=nwNxTtLLPTU0ewfLM7SSbrjMajMl+wwnFkCY/fi90vE=; b=kJ79AgmqFxbkmCXo+7c6wE6IDOnICT0965WnNzEBK5w9BpJYJth+zgfhvZ8RGTvQCj wku9H9VJz1aiD3vgfu/cHAqUxDI+hA9f4EfabavOF/OCa6PYkXIf9rEeVHPeH4rrpenz Kfc86VyMoBcxm/x+nEf1diwGwwEUz/OsVqwHDj3UF9Ts5rB4kacn/c/SlNaPUb/oNH0u EBPwNwxh3oCdFSKzuR1KktxBHQOXlJFDnco+crCB+e3sQ3faGMREDlA54YPTkSIVFcUI 5fHkF9gW0gC5yoUmqXXX9hfQu/VU99270ZEF9KMRgqEOuSfhlh7Us9/fr+J6Wf9dPZgY m5hQ==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=percona.com; s=google; t=1781040974; x=1781645774; darn=lists.postgresql.org; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :from:to:cc:subject:date:message-id:reply-to; bh=tIwa0VCHWpormTDLeTLZE0QVPs9muASNPB5rjC0Lukk=; b=R7cMHBKkl0/0yIjp597AF+bzRArHNu6pH4IQ8stJcjKZol1UcVvWSSzTHnb8KdTw3H qaP+/4Ln98PjZsVH8uFuyUlmJjN7bV3gyTuQ7agktLT+dP7eYrzn4WVjdeBtFq2HnBZi Rnr5fscEf8Z6BicQrPbhvbYKQv99dYzKiw+hjc8MIqh3XkpcmZdSVsgpSfi0m28pGkO5 pkIG+wCnBx2fuCVwxDvZk8li39qajP8ZYP6I4phzXYbUOHFp8DMjyn2VppLR0qDBs8lb fjpsfZJzXoPinTtB+Z2xbLkm1dVrK3KDLR3HDemHMoQ2821ibTQuuEASpQO+uUBo6tFg jupg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781040974; x=1781645774; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tIwa0VCHWpormTDLeTLZE0QVPs9muASNPB5rjC0Lukk=; b=eWocPnZDc5wgjtrPHP32HGGkDzODch0ERu5/DkJimKIKMA+0JSx+2UofGikf6umGnG nS6zDmI1I/IIp6PLf3AD7PwiqtoXwwZntXnLx7VeUxRxrXzAIBrL7JEwMv9+g87XRtRv 4x7EUM45bjmbyPFTXDevwK2RVEnVvCPyYYCz5IM7ODCsm67FdvYSWGs8WsflA+XEGZ2h 5CKrqyNyQ79wvvPXMZy58SX9AEc5g9+NdVPqBa7o8O35sXWj4cW6+sRj/dTOjJH90zNL 2YCHqa2gZuFaosrHNKnUVqSdul7rwcLw2z1awm3zpMfcIp2yP60JZ2rJv+Dt2RD2f1kl ZlTw== X-Gm-Message-State: AOJu0YyGewkf3cZ99CCyMCORYOhyP7pA1pEdXvjBtqnZwKy4uxykAJpH wrvN1pVP2y5I7dHeoav1+yWFTzt/pqnMpagVv2Va00PLNGkJ2sT/GjVcqgLwNb7CKydCWzdxIj/ AgzMyF1hlrlacy+pA1QYZSvPIzKOwu9js8fxvdFlsqBqbWSTbNjE60W0KUkjoby/JeBOYTtabXJ cI+wdpQgIfvssAdC5WXhY0D0qsS7laRoF4m4xi1Km5eiYXNJl8DAg7p1eugpJGheWkcObOaQVWP DH1sn+BqiQLmxazEFLNC06nOg4Pwa2pV7efVfOkVDUix5YvIHUNZrtNXPgP8NCaAX7le/eXO+8z GQ== X-Gm-Gg: Acq92OEcYBaCHYyKLTdh0RlXbGnpjAQNb6a6NBDUYn0jTUZsEk0IHReOBWFSGBFKhx5 QA3mE9kSbSEZFBqHBZ6b1g3zkpGMCvxHDAO0Cx7E+KblOUC8+j8ohs/2YT2XKlTGEz+qoiYX1bp WtZ3s+KneSNNXtDIQi5E44Guhb2ApC64jAyY+nR+84cPyt5W1WUgpfRAg7XSIsFWw4jHUFtOClb M/7Vt4Syzo5cQ/yJnJGdt2LMu9qtQwZ6tnpFcGPCuqs2U5qM5aznB2lVfUL1cB4NIUUZhd8Q5Br XtFoY8NaR7i3QinPExgCCvdZlXZVMcqCRb7yJKH+9Rbf3ahGOSpsTTkuwnXeCqD9PadScdNn+X8 U0z0= X-Received: by 2002:a05:690c:4588:b0:7dc:4ba:ee15 with SMTP id 00721157ae682-7ed0daa46e5mr228888797b3.43.1781040974203; Tue, 09 Jun 2026 14:36:14 -0700 (PDT) Received: from 298783833264 named unknown by gmailapi.google.com with HTTPREST; Tue, 9 Jun 2026 16:36:13 -0500 Received: from 298783833264 named unknown by gmailapi.google.com with HTTPREST; Tue, 9 Jun 2026 16:36:13 -0500 From: Zsolt Parragi In-Reply-To: References: MIME-Version: 1.0 Date: Tue, 9 Jun 2026 16:36:13 -0500 X-Gm-Features: AVVi8CcPIXJF5BsCYOtN8b-q6ZPLa3En0qQMgPv9T7xuGDJjfkaSiA-CQ589rWo Message-ID: Subject: Re: Support EXCEPT for TABLES IN SCHEMA publications To: pgsql-hackers@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" X-CLOUD-SEC-AV-Sent: true X-CLOUD-SEC-AV-Info: percona,google_mail,monitor X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > Do you mean other.t should be there? Yes, that was a typo in my example. > After considering, I chose to follow behavior similar to existing FOR > ALL TABLES publications to handle schema-switch cases. Today, if a > table excluded via EXCEPT is dropped, the corresponding prexcept entry > is removed, and recreating a table with the same name does not > automatically restore the exclusion. > > I applied the same principle to schema changes: once an excluded table > moves out of the schema, the exclusion is removed. I'm not that sure about the analogy. DROP TABLE is a destructive operation, executing DROP TABLE and then CREATE TABLE won't automatically bring back the data. With this approach, two cheap ALTER TABLE ... SET SCHEMA statements can clear an EXCEPT clause without the proper permissions. But I'm not sure what's the best solution for this. The v11 approach is at least more consistent than the previous behavior. > 1) Reject the schema change: Error out if a table with a prexcept > entry is moved between schemas. This feels overly restrictive. It is restrictive, but maybe it's the better solution? Or alternatively, maybe it should require proper permissions to remove the except clause? Another thing that could improve this if we would print out a warning that the statement caused a change in the publication? But then that's also a question for the preexisting drop table case.