From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Command Triggers, patch v11
Date: Mon, 19 Mar 2012 14:13:26 +0100
User-Agent: KMail/1.13.7 (Linux/3.3.0-rc5-andres-00066-g500dd23; KDE/4.6.5;
	x86_64; ; )
Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>,
	Dimitri Fontaine <dimitri@2ndquadrant.fr>
References: <m24nufq466.fsf@2ndQuadrant.fr>
	<201203172326.53461.andres@anarazel.de>
	<18353.1332095370@sss.pgh.pa.us>
In-Reply-To: <18353.1332095370@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201203191413.26729.andres@anarazel.de>

On Sunday, March 18, 2012 07:29:30 PM Tom Lane wrote:
> 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?)
I don't really see the use case but given the amount of work it probably takes 
it seems reasonable to allow that.

> 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.)
If we go down this route I think adding an eflag is the better choice. Thinking 
of it - my patch already added that ;)

> 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.
Hm. I am not *that* convinced anymore. It wasn't that much duplication in the 
end...

Andres