Re: Disallow UPDATE/DELETE on table with unpublished generated column as REPLICA IDENTITY
От | Amit Kapila |
---|---|
Тема | Re: Disallow UPDATE/DELETE on table with unpublished generated column as REPLICA IDENTITY |
Дата | |
Msg-id | CAA4eK1JhdWjKSAEOEeT1QLpyxeOiN+f-Pe75hhmVqe7LJ76qng@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Disallow UPDATE/DELETE on table with unpublished generated column as REPLICA IDENTITY (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Disallow UPDATE/DELETE on table with unpublished generated column as REPLICA IDENTITY
Re: Disallow UPDATE/DELETE on table with unpublished generated column as REPLICA IDENTITY |
Список | pgsql-hackers |
On Fri, Nov 8, 2024 at 5:17 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > On 2024-Nov-07, Amit Kapila wrote: > > > BTW, I was thinking as to how to fix it on back branches and it seems > > we should restrict to define REPLICA IDENTITY on stored generated > > columns in the first place in back branches as those can't be > > replicated. So, the following should fail: > > > > CREATE TABLE testpub_gencol (a INT, b INT GENERATED ALWAYS AS (a + 1) > > STORED NOT NULL); > > CREATE UNIQUE INDEX testpub_gencol_idx ON testpub_gencol (b); > > ALTER TABLE testpub_gencol REPLICA IDENTITY USING index testpub_gencol_idx; > > > > Peter, do you have an opinion on this? > > I think a blanket restriction of this sort is not a good idea (at least > in back branches), because there might be people using replica > identities with stacks other than pgoutput. > Do you mean to say that people using plugins other than pgoutput may already be sending generated columns, so defining replica identity should be okay for them? > > Would it work to enforce > the restriction when such a table is added to a publication? > But what if somebody defines REPLICA IDENTITY on the generated column after adding the table to the publication? -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: