| 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 22:17:10 |
| Message-ID: | CANP8+jJVK82tHfzHKz7w7oN_q1T1gPFMW+13LY4RuytfTr=3+g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 6 Nov 2018 at 13:16, Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> > 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
>
> Generated columns cannot have volatile expression results in them, so
> this case cannot happen.
>
> Also, we don't know whether the generation expression on the target is
> the same (or even if it looks the same, consider locale issues etc.), so
> we need to recompute the generated columns on the target anyway, so it's
> pointless to send the already computed stored values.
>
Makes sense.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2018-11-06 22:17:43 | Re: First-draft release notes for back-branch releases |
| Previous Message | Andres Freund | 2018-11-06 22:16:36 | Re: backend crash on DELETE, reproducible locally |