On Thu, Aug 29, 2024 at 8:44 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Wed, Aug 28, 2024 at 1:06 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > > > As Euler mentioned earlier, I think it's a decision not to replicate > > > generated columns because we don't know the target table on the > > > subscriber has the same expression and there could be locale issues > > > even if it looks the same. I can see that a benefit of this proposal > > > would be to save cost to compute generated column values if the user > > > wants the target table on the subscriber to have exactly the same data > > > as the publisher's one. Are there other benefits or use cases? > > > > > > > The cost is one but the other is the user may not want the data to be > > different based on volatile functions like timeofday() > > Shouldn't the generation expression be immutable? > > > or the table on > > subscriber won't have the column marked as generated. > > Yeah, it would be another use case. >
While speaking with one of the decoding output plugin users, I learned that this feature will be useful when replicating data to a non-postgres database using the plugin output, especially when the other database doesn't have a generated column concept. -- With Regards, Amit Kapila.
