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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers