Re: [HACKERS] Re: SELECT INTO TABLE busted?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Re: SELECT INTO TABLE busted? |
Дата | |
Msg-id | 21986.918333709@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: SELECT INTO TABLE busted? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
I found part of the SELECT INTO TABLE problem: at line 2872 of gram.y, n->istemp = (bool)((A_Const *)lfirst($4))->val.val.ival; the cast should be to Value* not A_Const*. On my machine, an uninitialized field is picked up and dropped into n->istemp, so that the system sometimes interprets SELECT INTO TABLE as SELECT INTO TEMP TABLE. Ooops. With this fix, the regression tests pass again (except the "don't know whether nodes of type 600 are equal" problem is still there). However, I can now report that there's a second bug involving trying to access a temp table after end of transaction. The query series (in the regression database) BEGIN; SELECT * INTO TEMP TABLE xacttest FROM aggtest; INSERT INTO xacttest (a, b) VALUES (777, 777.777); END; SELECT a FROM xacttest WHERE a > 100; crashes the backend. It seems to think that xacttest still exists, but it chokes trying to retrieve tuples from it. (Whether a non-temp table xacttest exists doesn't seem to matter, btw.) Am I right in thinking that the temp table should disappear at END TRANSACTION? regards, tom lane
В списке pgsql-hackers по дате отправления: