From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>
Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>
Subject: Re: Command Triggers, patch v11
Date: Mon, 19 Mar 2012 14:13:26 +0100
Message-ID: <201203191413.26729.andres@anarazel.de> (raw)
In-Reply-To: <18353.1332095370@sss.pgh.pa.us>
References: <m24nufq466.fsf@2ndQuadrant.fr>
<201203172326.53461.andres@anarazel.de>
<18353.1332095370@sss.pgh.pa.us>
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
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: andres@anarazel.de, tgl@sss.pgh.pa.us, thom@linux.com, dimitri@2ndquadrant.fr
Subject: Re: Command Triggers, patch v11
In-Reply-To: <201203191413.26729.andres@anarazel.de>
* 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