Re: Disallow UPDATE/DELETE on table with unpublished generated column as REPLICA IDENTITY

From: Aleksander Alekseev <aleksander(at)timescale(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>
Subject: Re: Disallow UPDATE/DELETE on table with unpublished generated column as REPLICA IDENTITY
Date: 2024-11-05 14:25:36
Message-ID: CAJ7c6TOnMoQZsrg6ZaEc_speRuPyC2F+Tfqgn2_U-Rm+TDVCDw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Shlok,

> Here the generated column 'b' is set as REPLICA IDENTITY for table
> 'testpub_gencol'. When we create publication 'pub_gencol' we do not
> specify any column list, so column 'b' will not be published.
> So, the update message generated by the last UPDATE would have NULL
> for column 'b'.
>
> To avoid the issue, we can disallow UPDATE/DELETE on table with
> unpublished generated column as REPLICA IDENTITY. I have attached a
> patch for the same.

I don't think this would be a correct fix. Let's say I *don't* have
any publications:

```
=# CREATE TABLE testpub_gencol (a INT, b INT GENERATED ALWAYS AS (a + 1)
STORED NOT NULL);
CREATE TABLE

=# CREATE UNIQUE INDEX testpub_gencol_idx ON testpub_gencol (b);
CREATE INDEX

=# INSERT INTO testpub_gencol (a) VALUES (1);
INSERT 0 1

=# UPDATE testpub_gencol SET a = 100 WHERE a = 1;
UPDATE 1
eax=# SELECT * FROM testpub_gencol ;
a | b
-----+-----
100 | 101
(1 row)
```

So far everything works fine. You are saying that when one creates a
publication UPDATEs should stop working. That would be rather
surprising behavior for a typical user not to mention that it will
break the current behavior.

I believe one would expect that both UPDATEs and the publication
should continue to work. Perhaps we should forbid the creation of a
publication like this instead. Or alternatively include a generated
column to the publication list if it's used as a replica identity. Or
maybe even keep everything as is.

Thoughts?

--
Best regards,
Aleksander Alekseev

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2024-11-05 14:39:56 Re: Pgoutput not capturing the generated columns
Previous Message Andreas Karlsson 2024-11-05 14:18:10 Re: Always have pg_dump write rules in a consistent order