Tom Lane wrote:
> KaiGai Kohei <kaigai@ak.jp.nec.com> writes:
>> If my understanding is correct, the following patch can fix the matters.
>
>> ! if (ExecContextForcesOids(ps, &hasoid) &&
>> ! hasoid != tupdesc->tdhasoid)
>> return false;
>> --- 243,249 ----
>> ! if (ExecContextForcesOids(ps, &hasoid))
>> return false;
>
> This isn't fixing anything, it's just making the executor stick its
> head in the sand.
Sorry, it is unclear for me why it does not fix anything.
In my understanding, the matter comes from the mixture of two kind of
tuples. The one has object identifier, and the other don't have.
It seems to me the current implementation assumes fetched tuples have
proper rowtype which matches to the current table definition, however,
the ALTER TABLE can break this assumption. It makes impossible to guess
ahead whether fetched tuples have its object identifier, or not.
Therefore, I thought we need something to enforce proper rowtype
prior to when a tuple is delivered to ExecInsert() as a new one.
The patch enforces ExecProject() when INSERT, UPDATE or SELECT INTO
cases, so it enables to deliver a tuple with proper rowtype.
In addition, what is the expected behavior in the following case?
I felt it a bit strange one, so reported.
======== postgres=# CREATE TABLE t1 (a int, b text) WITH OIDS; CREATE TABLE postgres=# INSERT INTO t1 VALUES (1,'aaa'),
(2,'bbb'),(3,'ccc'); INSERT 0 3 postgres=# SELECT oid,* FROM t1; oid | a | b -------+---+----- 16405 | 1 | aaa
16406| 2 | bbb 16407 | 3 | ccc (3 rows)
postgres=# INSERT INTO t1 (SELECT * FROM t1); INSERT 0 3 postgres=# SELECT oid,* FROM t1; oid | a | b
-------+---+----- 16405 | 1 | aaa 16406 | 2 | bbb 16407 | 3 | ccc 16405 | 1 | aaa <--- newly inserted tuples
preservethe object 16406 | 2 | bbb identifier of its source tuples, not a newly 16407 | 3 | ccc assigned
one.(6 rows)
========
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
