Re: A bug with ALTER TABLE SET WITHOUT OIDS in CVS HEAD

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>