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
