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

  1. Generated columns

  2. Add walreceiver API to get remote server version

  3. Add pg_partition_tree to display information about partitions

  4. pg_restore: Augment documentation for -N option

  5. Change delimiter used for display of NextXID