|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: Command Triggers|
|Views:||Raw Message | Whole Thread | Download mbox|
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
> 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
|Next Message||Alvaro Herrera||2011-12-04 02:14:20||Re: Review: Non-inheritable check constraints|
|Previous Message||Andrew Dunstan||2011-12-04 00:45:49||Re: [PATCH] PostgreSQL fails to build with 32bit MinGW-w64|