Re: [HACKERS] generated columns
| От | Simon Riggs |
|---|---|
| Тема | Re: [HACKERS] generated columns |
| Дата | |
| Msg-id | CANP8+jJwr02Yt_ZD6XtAg-y8eQ5vg4VSEpXTkNM8P4t0iqHtYg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] generated columns (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
| Ответы |
Re: [HACKERS] generated columns
|
| Список | pgsql-hackers |
On Tue, 6 Nov 2018 at 04:31, Peter Eisentraut <peter.eisentraut@2ndquadrant.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/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: