From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: andreas@visena.com, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: ERROR: attribute number 6 exceeds number of columns 5
Date: Tue, 07 Jan 2020 11:53:19 -0500
Message-ID: <18651.1578415999@sss.pgh.pa.us> (raw)
In-Reply-To: <20191127.120034.20463388950832898.horikyota.ntt@gmail.com>
References: <VisenaEmail.200.231b0a41523275d0.16ea7f800c7@tc7-visena>
<6352.1574783351@sss.pgh.pa.us>
<20191127.120034.20463388950832898.horikyota.ntt@gmail.com>
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> At Tue, 26 Nov 2019 10:49:11 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in
>> Hmm, interesting. IMO, that *should* have thrown an error, but of
>> course not that one. The ADD COLUMN operations are all processed
>> in parallel, so it's not okay for one of them to have a GENERATED
>> expression that refers to another one of the new columns. But you
>> should have gotten a "no such column" type of error, not a run-time
>> cross-check failure.
> Something like this works?
I started to look at this, but it felt a bit brute-force to me.
After awhile I began to think that my offhand comment above was
wrong --- why *shouldn't* this case work? When we insert or
update a tuple, we expect that GENERATED columns should be
computed based on the new tuple values, so why is the executor
evidently evaluating them based on the old tuple?
That thought soon led me to realize that there's an adjacent
bug that this patch fails to fix:
regression=# create table foo (f1 int);
CREATE TABLE
regression=# insert into foo values(1),(2);
INSERT 0 2
regression=# alter table foo alter column f1 type float8, add column f2 int generated always as (f1 * 2) stored;
ERROR: attribute 1 of type foo has wrong type
DETAIL: Table has type integer, but query expects double precision.
So I believe that the real problem here is that the executor is
evaluating GENERATED expressions at the wrong time. It's evaluating
them against the pre-conversion tuples when it should be evaluating
them against the post-conversion tuples. We need to go fix that,
rather than inserting arbitrary restrictions in the DDL code.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, horikyota.ntt@gmail.com, peter.eisentraut@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
Subject: Re: ERROR: attribute number 6 exceeds number of columns 5
In-Reply-To: <18651.1578415999@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox