Re: [HACKERS] generated columns
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndquadrant.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Erik Rijkers <er@xs4all.nl>, Sergei Kornilov <sk@zsrv.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>,
Michael Paquier <michael.paquier@gmail.com>, Jaime Casanova <jaime.casanova@2ndquadrant.com>
Date: 2018-11-06T13:28:16Z
Lists: 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/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Generated columns
- fc22b6623b6b 12.0 landed
-
Add walreceiver API to get remote server version
- 69039fda837d 12.0 landed
-
Add pg_partition_tree to display information about partitions
- d5eec4eefde7 12.0 cited
-
pg_restore: Augment documentation for -N option
- 2fe42baf7c1a 12.0 cited
-
Change delimiter used for display of NextXID
- 59a884e9854c 9.6.0 cited