From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>
Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>
Subject: Re: Command Triggers, patch v11
Date: Sat, 17 Mar 2012 11:02:47 -0400
Message-ID: <7094.1331996567@sss.pgh.pa.us> (raw)
In-Reply-To: <201203162317.43818.andres@anarazel.de>
References: <m24nufq466.fsf@2ndQuadrant.fr>
<201203162237.38813.andres@anarazel.de>
<21818.1331934775@sss.pgh.pa.us>
<201203162317.43818.andres@anarazel.de>
Andres Freund <andres@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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, thom@linux.com, dimitri@2ndquadrant.fr
Subject: Re: Command Triggers, patch v11
In-Reply-To: <7094.1331996567@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox