| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Command Triggers |
| Date: | 2011-12-02 02:09:55 |
| Message-ID: | 19167.1322791795@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-12-02 02:15:14 | Re: Inlining comparators as a performance optimisation |
| Previous Message | Robert Haas | 2011-12-02 01:31:06 | Re: Inlining comparators as a performance optimisation |