Re: [HACKERS] generated columns

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] generated columns
Date: 2018-01-30 08:17:13
Message-ID: 20180130081713.GB21433@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Verite 2018-01-30 08:31:29 csv format for psql
Previous Message Tatsuro Yamada 2018-01-30 08:06:16 Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan