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 по дате отправления:

Предыдущее
От: Michael Meskes
Дата:
Сообщение: Re: [HACKERS] DEC OSF1 Compilation problems
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] equal: don't know whether nodes of type 600 are equal