| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | Erik Rijkers <er(at)xs4all(dot)nl>, Sergei Kornilov <sk(at)zsrv(dot)org>, PostgreSQL-development <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 13:28:16 |
| Message-ID: | CANP8+jJwr02Yt_ZD6XtAg-y8eQ5vg4VSEpXTkNM8P4t0iqHtYg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 6 Nov 2018 at 04:31, Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> 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.
>
IMHO...
Virtual generated columns need not be WAL-logged, or sent.
Stored generated columns should be treated just like we'd treat a column
value added by a trigger.
e.g. if we had a Timestamp column called LastUpdateTimestamp we would want
to send that value
> Similar considerations also apply to foreign tables. What is the
> meaning of a stored generated column on a foreign table?
>
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Verite | 2018-11-06 13:57:15 | Re: csv format for psql |
| Previous Message | Alvaro Herrera | 2018-11-06 12:53:37 | Re: ON COMMIT actions and inheritance |