Andres Freund <and...@anarazel.de> writes: > On Friday, March 16, 2012 10:52:55 PM Tom Lane wrote: >> Something else I just came across is that there are assorted places that >> are aware that ExplainStmt contains a Query, eg setrefs.c, plancache.c, >> and those have got to treat CreateTableAsStmt similarly.
> Hm. Is that so? As implemented in my version the planner just sees a plain > statement instead of a utility statement. Am I missing something? Well, the work flow for EXPLAIN is: parse analysis: recursively do parse analysis on contained query plan: do nothing execution: call planner on contained query, then optionally run it and the reason for doing it that way is explained by transformExplainStmt: * EXPLAIN is like other utility statements in that we emit it as a * CMD_UTILITY Query node; however, we must first transform the contained * query. We used to postpone that until execution, but it's really necessary * to do it during the normal parse analysis phase to ensure that side effects * of parser hooks happen at the expected time. ISTM that argument applies just as much to CREATE TABLE AS, especially in view of the fact that we're restructuring the SELECT INTO case, in which parse analysis of the SELECT certainly does happen early. It's also not clear to me why it wouldn't apply to COPY (SELECT ...). I'm not going to touch the COPY (SELECT ...) issue right now, but somebody ought to go back and check up on the exact user-visible bugs that motivated moving EXPLAIN's parse analysis processing. (I suspect it had to do with plpgsql variable processing, but too lazy to go look right now.) If there's a plausible use case where similar bugs could be exhibited in COPY, we're going to have to restructure that too. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers