In
http://archives.postgresql.org/message-id/52ccaa8f414ba8anzai-na...@mxu.nes.nec.co.jp
it's pointed out that our documentation claims the WITH [NO] DATA option
works for all variants of CREATE TABLE AS. But in fact it's only
implemented for the SelectStmt variant, not for the ExecuteStmt variant,
and the ugly kluge used for SelectStmt (paste on a LIMIT 0 at parse
time) isn't going to work for the ExecuteStmt case.
What I'm considering doing to improve this is to add a bool field
"skipData" or some such to IntoClause. By default that would be false,
but the CREATE TABLE AS productions could set it true when they have
WITH NO DATA. Then we'd need to add an execution-time test; the most
expedient way seems to be to add something like this to ExecutorRun:
if (estate->es_select_into &&
queryDesc->plannedstmt->intoClause->skipData)
direction = NoMovementScanDirection;
which will cause it to skip the ExecutePlan call. In the normal case
this adds just one boolean test to ExecutorRun, so I don't think it
represents a measurable slowdown. The EXECUTE code path needs no
changes since it's just passing the IntoClause through to the executor.
While at it, it occurs to me that we could handle the
IntoClause.colNames option for the ExecuteStmt case if we were to move
the responsibility for plastering on the substitute column names into
the executor's OpenIntoRel, instead of making parse analysis do this
(which is also pretty klugy, see applyColumnNames callers).
Any objections or better ideas?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
