I've got the CREATE TABLE AS restructuring almost finished, but came
across something that I could use some advice on. The current code
stores the "into" relation (and whether or not that relation has OIDs)
in the Query struct. This is ugly[1], but I'm not sure how to fix it.
The main reason Query needs to hold this data is so that InitPlan() can
produce the correct TupleDesc for the query's result set in
ExecutorStart() (it needs to know, for example, whether to include space
for OIDs in the TupleDesc).
Based on that, I think that moving this information into QueryDesc might
be doable, but I'm not sure if this will have negative implications
anywhere.
Any thoughts?
-Neil
[1] IMHO it is ugly because:
(a) "Query" is the product of the analyzer, but it is possible for the
INTO relation to change between parse-analysis and execution (consider
CREATE TABLE AS ... EXECUTE). We currently cope with this by copying the
Query and modifying it.
(b) The INTO relation is really a property of the statement to which the
SELECT/EXECUTE is attached, not the SELECT itself. In other words, in a
statement like:
CREATE TABLE xyz AS SELECT ...;
The "destination" of the SELECT query is a property of the CREATE TABLE
AS statement, not the SELECT. The new implementation of CREATE TABLE AS
works just like this: the executor is run as normal, but it just uses a
special DestReceiver that dumps the SELECTs result set into a
newly-created heap table. Needing to modify the attached SELECT's Query
node to "let it know" that it is being invoked by CREATE TABLE AS is
ugly.
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
