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 1w9Mn7-001NWp-1A for pgsql-bugs@arkaria.postgresql.org; Sun, 05 Apr 2026 12:41:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w9Mn5-002lKJ-2c for pgsql-bugs@arkaria.postgresql.org; Sun, 05 Apr 2026 12:41:24 +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 1w9Mn5-002lKB-1I for pgsql-bugs@lists.postgresql.org; Sun, 05 Apr 2026 12:41:23 +0000 Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w9Mn3-00000000gAl-23Ce for pgsql-bugs@lists.postgresql.org; Sun, 05 Apr 2026 12:41:22 +0000 Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-66ee071fe35so225988a12.3 for ; Sun, 05 Apr 2026 05:41:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775392880; cv=none; d=google.com; s=arc-20240605; b=eVvk8gaP3UqdIIim2JkIsY7CN4DSi7fFkq0yRXOGkdzHFRWUNKJZGB/J+xzYdAcVip OmrsMmW5aq8NI1RRLIj+6LJkJzGcOG/dAdvEjlBrE9O5WwUTvGPDtkgUac0rKR5ubOwK HRYgbTr5nRHXiSG6S7MndL+fUepjB8HpMCC+kFZQnITSvBw/3Z9BShQeazC9mnk4t8aQ yxrnFHEs8X6tKx8f3mS6W3Cpkz3TpCSz7m291UQmYH69BNVJMgpqWVMsqdFfKhXuBxdG hvdNzovsYQdXJjQIFUe6lqHIpDEkAYPKmcQ7A1TCLqo9mGrMui6wCzLQQqgfZzZw/fHT ILXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=6sODWu6vGYGAzSHeeVpdBOp73xcg0xRZr+f6z0ZS71A=; fh=PE1xl+gt3axCXZHLkcc4Wpx4rm3nA593nXV8w9ZO4jY=; b=kYB1q1DgMdVEOkXcsLQGbpyCeDa+A+H6HHLcRvvrs9OXjE9xcFlj0smTbqKcCfNVYy 7i0hshw/9KR5JByob0tPE4c4NcW7q6BW90aOmvQd5LmzRrxT7JEdw6fbR32zyNA0Tn4a YypIwUcDGbnPtjmXsF2uoBdrH22KYxoTmDs2FwkfNqseo9eZmQPLXWK8Tm91ItQt/dRN 0KDOI3BaySCm43Llx9gvEFoZjcw2wkZQRBs00F300LAdRegFvVPt4JTMWm66wjYLKCyi kwkplPgt6PkyFK3/4CSFDiHpNqiaZS5teL49kbO7fSRREGHoOhBRZnd+WwjwUIqr/Rep qr3A==; 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=gotab.io; s=google; t=1775392880; x=1775997680; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6sODWu6vGYGAzSHeeVpdBOp73xcg0xRZr+f6z0ZS71A=; b=Mw+PSxk+OMGcD/Mow5bV1GrrpTEuwv+i5j7bWF4fQO4yZ6tnJ2wtQSVfCHJ2upoZgs bhG4JB+SaP7clJcDeoca+0lWr2GSHV9LiYxRPE7E1BldkV8XNAtOb/KEBibOk3ktPnnh pZRxsN9dPRQwrjhqemR15O7v4dtERa+1OV3DQOQZwAvBnw/RiLUmXDeOMJXQyYQ5k2BS Z65RCCnptpYeLrW1apN7v6fuDK0vFi5ASMuxxAovuVDNBZ9d3/uus/tDM66G1/DkeO4z 7Db0d00xt+1VgpHdfBki8fMz74YCowep9SaBkaEFf3WUe3hCBMHBKb6odVvR0E/kBHgY BCXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775392880; x=1775997680; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6sODWu6vGYGAzSHeeVpdBOp73xcg0xRZr+f6z0ZS71A=; b=hcTQtX1B3lPOe46VQGkCKH74M2GwQfX2Zt/pp8po1ju4mkXoFcMZv1xIx42ETDVk4J osHvYxM2Jhy7QH1nPnvj932oJh0dSubRGL5ZpoymNkERjH+YkokzFGl//mjXnhOQNgie cj/pNJCWuCc9Rx8WCgKPyD0W92cgc9Hb8VO/VW7xVmL/VwKFGcZomb6L7LtUyB3iLxGg Rd1t336N8Ipqs93pHQPKhOWe5KztKCaONNH7K0iIybFzs9BVU+XkfQSIzSQoQ054fmCp Z8mmFs+D+cTnQgyBeBc8xVeL4dtGE4E7RN69cK8o/AuohgsWmWLtGsRrmQcbBArUogDw YOCw== X-Gm-Message-State: AOJu0YywunrvIAPeYxLa6aL2Oxfx8ENKpMu5PvGvNtMwMzcTadi1kuAI HnzPKV/03xz0rl/Wo0eiRoQQ4QcW4QHojR6g6Gen7jPDkaoTr+gNXpTiByWNifN21qMgO9HaDYJ fu8yHgI6OMApRxQXDg+n1OxMhnZjb4mx0t1Dt4A5A8w== X-Gm-Gg: AeBDietc+JBcDBjkuE7b/B1qx5mA90wDxI/lUKKXgN90tSXJ6g8ghoGKi+puZVXzGSV rc3SJQcaco1ZlE4TIZ5KWt0X4RRbRMd5/P8qi33ZghyAOKMXgZHpR+f5rFO7wkZBrZX8wfQ8sFO e8ep9uIQSQ8usToXYL98hsdMrxMR9Fgt4Wd7Dx4Kwzx1R5RDIi9XtBAXTIRQAenvv4uBORMvDq3 XuUbA4qYPgEAG5Ux1Wv0Z0EQPaob5t353uySR12Przm/e5ha8tSUsATD6QGOF457y7b+D+TRJjv rUASESE7QYc1cbOEKhwf213uPKqMSvAROyw7E1gZZ6YWwCHiNojUOhqsMThK6SGEWmExsibt6MB rXyfSYQM= X-Received: by 2002:a05:6402:3253:b0:66d:cfa5:9707 with SMTP id 4fb4d7f45d1cf-66e3e8c6b61mr3052009a12.0.1775392879590; Sun, 05 Apr 2026 05:41:19 -0700 (PDT) MIME-Version: 1.0 References: <19434-297bf2cbd8d2931a@postgresql.org> In-Reply-To: From: Tim McLaughlin Date: Sun, 5 Apr 2026 08:41:08 -0400 X-Gm-Features: AQROBzDLv4d6Y73Mt8HFVgobbS0anlbvc7PY-vPbs0eR0hacZqQ55Yrn6plRQ9w Message-ID: Subject: Re: BUG #19434: adding WHERE to a publication can cause UPDATEs and DELETEs to fail on the source table To: Greg Sabino Mullane Cc: pgsql-bugs@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000ecd155064eb5dd0b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ecd155064eb5dd0b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Greg, I'm actually working on another project that uses CDC for fraud detection and it occurred to me that it would be really great if there was an explicit way to just add a column to the "important columns" in general when the table is added to a publication. I'm currently using a pg_logical_embed_message to do it, but it would be a lot cleaner if there was something like this: ALTER PUBLICATION mypublication ADD TABLE users (user_id, firstname) INCLUDE (account_id) WHERE (status =3D 'ACTIVE'); It would effectively then have account_id & status always included in the NEW column. Cheers, Tim On Mon, Mar 23, 2026 at 12:47=E2=80=AFPM Greg Sabino Mullane wrote: > I don't think this is really a bug, more of a feature request / > optimization. However, I do agree this is an important one. I don't see > offhand why we can't append the where list to our existing list of > important columns. There would be a few downsides, but none that would be > worse than going full replica identity or creating a new index. I'll see > about making a proof of concept patch and throwing it on -hackers. Will c= c > you on that. > > Cheers, > Greg > > --000000000000ecd155064eb5dd0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greg,
I'm actually working on another p= roject that uses CDC for fraud detection and it occurred to me that it woul= d be really great if there was an explicit way to just add a column to the = "important columns" in general when the table is added to a publi= cation.=C2=A0 I'm currently using a pg_logical_embed_message to do it, = but it would be a lot cleaner if there was something like this:
=
ALTER PUBLICATION mypublication ADD TABLE users (user_id, firstname) 
IN= CLUDE (account_id) WHERE (status =3D 'ACTIVE');
It = would effectively then have account_id & status always included in the = NEW column.

Cheers,
Tim


On Mon, Mar 23, 2026 at 12:4= 7=E2=80=AFPM Greg Sabino Mullane <= htamfids@gmail.com> wrote:
I don't think this is really a bug, = more of a feature request / optimization. However, I do agree this is an im= portant one. I don't see offhand why we can't append the where list= to our existing list of important columns. There would be a few downsides,= but none that would be worse than going full replica identity or creating = a new index. I'll see about making a proof of concept patch and throwin= g it on -hackers. Will cc you on that.

Cheers,
Greg

--000000000000ecd155064eb5dd0b--