Re: [HACKERS] Re: SELECT INTO TABLE busted? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Re: SELECT INTO TABLE busted?
Date
Msg-id 21986.918333709@sss.pgh.pa.us
Whole thread Raw
In response to Re: SELECT INTO TABLE busted?  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Michael Meskes
Date:
Subject: Re: [HACKERS] DEC OSF1 Compilation problems
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] equal: don't know whether nodes of type 600 are equal