Re: Pgoutput not capturing the generated columns

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Pgoutput not capturing the generated columns
Дата
Msg-id CAA4eK1+5=NGAqfqhT67rKQC=RKfa+DEx4KaLbLzW-cD4aiKYXw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Pgoutput not capturing the generated columns  (Peter Smith <smithpb2250@gmail.com>)
Список pgsql-hackers
On Wed, Oct 23, 2024 at 12:26 PM Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Wed, Oct 23, 2024 at 5:21 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> > Additional comment on the 0003 patch
> > +# =============================================================================
> > +# Misc test.
> > +#
> > +# A "normal -> generated" replication.
> > +#
> > +# In this test case we use DROP EXPRESSION to change the subscriber generated
> > +# column into a normal column, then verify replication works ok.
> > +# =============================================================================
> >
> > In patch 0003, why do we have the above test? This doesn't seem to be
> > directly related to this patch.
> >
> > --
>
> Perhaps the test should be turned around, to test this feature more directly...
>
> e.g. Replication of table tab(a int, b int) ==>  tab(a int, b int, c int)
>
> test_pub=# create table tab(a int, b int);
>
> then, dynamically add a generated column "c" to the publisher table
> test_pub=# alter table tab add column c int GENERATED ALWAYS AS (a + b) STORED;
> test_pub=# insert into tab values (1,2);
>
> then, verify that replication works for the newly added generated
> column "c" to the existing normal column "c" at the subscriber.
>

This is testing whether the invalidation mechanism works for this case
which I see no reason to not work as this patch hasn't changed
anything in this regard. We should verify this but not sure it will
add much value in keeping this in regression tests.

--
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления: