On Friday, December 02, 2011 03:09:55 AM Tom Lane wrote:> Andres Freund <andres(at)anarazel(dot)de> writes:> > On Thursday, December 01, 2011 07:21:25 PM Tom Lane wrote:> >> Making this work cleanly would be a bigger deal than I think you're> >> thinking.> > > > Obviously that depends on the definition of clean...> > > > Changing the grammar to make that explicit seems to involve a bit too> > many changes on a first glance. The cheap way out seems to be to make> > the decision in analyze.c:transformQuery.> > Would that be an acceptable way forward?> > ITYM transformStmt, but yeah, somewhere around there is probably> reasonable. The way I'm imagining this would work is that IntoClause> disappears from Query altogether: analyze.c would build a utility> statement> CreateTableAs, pull the IntoClause out of the SelectStmt structure and> put it into the utility statement, and then proceed much as we do for> ExplainStmt (and for the same reasons).I have a patch which basically does all this minus some cleanup. I currently do the the differentiation for SELECT INTO (not CREATE AS, thats done in gram.y) in raw_parser but thats quick to move if others don't aggree on that.

I have two questions now:

First, does anybody think it would be worth getting rid of the duplication from OpenIntoRel (formerly from execMain.c) in regard to DefineRelation()?I noticed that there already is some diversion between both. E.g. CREATE TABLE frak TABLESPACE pg_global AS SELECT 1; is possible while it would be forbidden via a plain CREATE TABLE. (I will send a fix for this separately).

Secondly, I am currently wondering whether it would be a good idea to use the ModifyTable infrastructure for doing the insertion instead an own DestReceiver infrastructure thats only used for CTAS.It looks a bit too complicated to do this without removing the bulk insert and HEAP_INSERT_SKIP_WAL optimizations.