| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Erikjan Rijkers <er(at)xs4all(dot)nl>, Sergei Kornilov <sk(at)zsrv(dot)org> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com> |
| Subject: | Re: [HACKERS] generated columns |
| Date: | 2018-11-06 12:31:49 |
| Message-ID: | 6c9cc29a-64eb-d033-0909-b93f3a2b8c63@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 31/10/2018 08:58, Erikjan Rijkers wrote:
> I have also noticed that logical replication isn't possible on tables
> with a generated column. That's a shame but I suppsoe that is as
> expected.
This is an issue we need to discuss. How should this work?
The simplest solution would be to exclude generated columns from the
replication stream altogether.
Similar considerations also apply to foreign tables. What is the
meaning of a stored generated column on a foreign table?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Raiskup | 2018-11-06 12:43:03 | Re: plruby: rb_iterate symbol clash with libruby.so |
| Previous Message | Evgeniy Efimkin | 2018-11-06 12:28:30 | Re: Special role for subscriptions |