On 2024-Nov-09, Amit Kapila wrote: > On Fri, Nov 8, 2024 at 5:17 PM Alvaro Herrera <alvhe...@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.
> > 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? Yes. > If we don't want to add a restriction to not create replica identity > on generated columns then I think the solution similar to HEAD should > be okay which is to restrict UPDATE/DELETE in such cases. Hmm, I don't know about this. Maybe nobody cares, but I'm uneasy about it. I'm wondering about hypothetical cases where people is already using this combination of features in stable branches, without pgoutput. I think it's not great to add restrictions that didn't exist when they upgraded to some stable branch. In branch master it's probably okay, because they'll have to test before upgrading and they'll realize the problem and have the chance to adjust (or complain) before calling the upgrade good. But if we do that for stable branches, we'd deprive them of the ability to do minor upgrades, which would be Not Good. So, another option is to do nothing for stable branches. > > 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? Well, maybe we can restrict the change of REPLICA IDENTITY if the table is already in a pgoutput publication? On 2024-Nov-12, Amit Kapila wrote: > Also, another point against restricting defining REPLICA IDENTITY on > generated columns is that we do allow generated columns to be PRIMARY > KEY which is a DEFAULT for REPLICA IDENTITY, so that also needs to be > restricted. That won't be a good idea. Oh, that's a good point too. It's not clear to me why doesn't pgoutput cope with generated columns in replica identities. Maybe that can be reconsidered? -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "La persona que no quería pecar / estaba obligada a sentarse en duras y empinadas sillas / desprovistas, por cierto de blandos atenuantes" (Patricio Vogel)
