Re: assertion failure w/extended query protocol - Mailing list pgsql-hackers

From Andres Freund
Subject Re: assertion failure w/extended query protocol
Date
Msg-id 201210192124.29004.andres@2ndquadrant.com
Whole thread Raw
In response to Re: assertion failure w/extended query protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: assertion failure w/extended query protocol
List pgsql-hackers
On Friday, October 19, 2012 09:05:30 PM Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > Simple fix attached.
> 
> Are you sure this isn't just moving the failure conditions around?

Don't think so. Its not that easy to follow though...

The "CREATE OptTemp TABLE create_as_target AS EXECUTE "  production puts an 
ExecuteStmt into CreateTableAsStmt->query.
"CREATE OptTemp TABLE create_as_target AS SelectStmt" puts a SelectStmt in 
there.

then

static Query *
transformCreateTableAsStmt(ParseState *pstate, CreateTableAsStmt *stmt)
{Query       *result;
/* transform contained query */stmt->query = (Node *) transformStmt(pstate, stmt->query);
/* represent the command as a utility Query */result = makeNode(Query);result->commandType =
CMD_UTILITY;result->utilityStmt= (Node *) stmt;
 
return result;
}

guarantees that we have a Query with IsA(Query->utilityStmt, 
CreateTableAsStmt). And CreateTableAsStmt->query is the result of 
transformStmt(SelectStmt|ExecuteStmt). A transformed SelectStmt returns a 
Query with commandType == CMD_SELECT. A transformed ExecuteStmt returns a new 
Query node with commandType == CMD_UTILITY and the original ExecuteStmt as 
utilityStmt.

So as far as I can see the new logic is correct? A quick look & test seems to 
confirm that.

Greetings,

Andres
-- 
Andres Freund        http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [PATCH] Support for Array ELEMENT Foreign Keys
Next
From: Hitoshi Harada
Date:
Subject: Re: hash_search and out of memory