Re: [HACKERS] generated columns

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(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-27 22:05:14
Message-ID: c6690a91-a927-5c58-9e6b-5c4b14c5323d@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/26/18 12:46, Robert Haas wrote:
> On Thu, Jan 25, 2018 at 10:26 PM, Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>>> Does the SQL spec mention the matter? How do other systems
>>> handle such cases?
>>
>> In Oracle you get the same overflow error.
>
> That seems awful. If a user says "SELECT * FROM tab" and it fails,
> how are they supposed to recover, or even understand what the problem
> is? I think we should really try to at least generate an errcontext
> here:
>
> ERROR: integer out of range
> CONTEXT: while generating virtual column "b"
>
> And maybe a hint, too, like "try excluding this column".

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.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-01-27 22:53:40 Re: Write lifetime hints for NVMe
Previous Message Peter Eisentraut 2018-01-27 22:00:17 Re: [HACKERS] GnuTLS support