Horton

Re: [HACKERS] generated columns

Michael Paquier <michael.paquier@gmail.com>

View thread View on postgr.es
From: Michael Paquier <michael.paquier@gmail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Jaime Casanova <jaime.casanova@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-01-30T08:17:13Z
Lists: pgsql-hackers 
On Sat, Jan 27, 2018 at 05:05:14PM -0500, Peter Eisentraut wrote:
> This is expanded in the rewriter, so there is no context like that.
> This is exactly how views work, e.g.,
> 
> create table t1 (id int, length int);
> create view v1 as select id, length * 1000000000 as length_in_nanometers
> from t1;
> insert into t1 values (1, 5);
> select * from v1;
> ERROR:  integer out of range
> 
> I think this is not a problem in practice.

Yeah, I tend to have the same opinion while doing a second pass on the
patch proposed on this thread.  You could more context when using STORED
columns, but for VIRTUAL that does not make such sense as the handling
of values is close to views.  That's the same handling for materialized
views as well, you don't get any context when facing an overflow when
either creating the matview or refreshing it.
--
Michael

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