To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>,
	Dimitri Fontaine <dimitri@2ndquadrant.fr>
Subject: Re: Command Triggers, patch v11 
In-reply-to: <201203172326.53461.andres@anarazel.de> 
References: <m24nufq466.fsf@2ndQuadrant.fr> <9503.1332006327@sss.pgh.pa.us>
	<24814.1332021870@sss.pgh.pa.us>
	<201203172326.53461.andres@anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Sat, 17 Mar 2012 23:26:53 +0100"
Date: Sun, 18 Mar 2012 14:29:30 -0400
Message-ID: <18353.1332095370@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

BTW, I've been looking through how to do what I suggested earlier to get
rid of the coziness and code duplication between CreateTableAs and the
prepare.c code; namely, let CreateTableAs create a DestReceiver and then
call ExecuteQuery with that receiver.  It appears that we still need at
least two bits of added complexity with that approach:

1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
that it can enforce that the prepared query is a SELECT.  (BTW, maybe
this should be weakened to "something that returns tuples", in view of
RETURNING?)

2. Since ExecuteQuery goes through the Portal machinery, there's no way
for it to pass in eflags to control the table OIDs setup.  This is
easily solved by adding an eflags parameter to PortalStart, which
doesn't seem too awful to me, since the typical caller would just pass
zero.  (ExecuteQuery would also have to know about testing
interpretOidsOption to compute the eflags to use, unless we add an
eflags parameter to it, which might be the cleaner option.)

In short I'm thinking: add an eflags parameter to PortalStart, and add
both an eflags parameter and a "bool mustReturnTuples" parameter to
ExecuteQuery.  This definitely seems cleaner than the current
duplication of code.

			regards, tom lane