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
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 |