[2002-01-12 23:45] Tom Lane said:
| Bruce Momjian <pgman@candle.pha.pa.us> writes:
| > I am testing pg_upgrade. I successfully did a pg_upgrade of a 7.2
| > regression database into a fresh 7.2 install. I compared the output of
| > pg_dump from both copies and found that c_star dump caused a crash. I
| > then started doing more testing of the regression database and found
| > that the regression database does not load in cleanly.
|
| No kidding. That's been a known issue for *years*, Bruce. Without a
| way to reorder the columns in COPY, it can't be fixed. That's the main
| reason why we have a TODO item to allow column specification in COPY.
The attached patch is a first-cut at implementing column specification
in COPY FROM with the following syntax.
COPY atable (col1,col2,col3,col4) FROM ...
The details:
Add "List* attlist" member to CopyStmt parse node.
Adds <please supply term ;-)> to gram.y allowing opt_column_list
in COPY FROM Node.
In CopyFrom, if attlist present, create Form_pg_attribute* ordered
same as attlist.
If all columns in the table are not found in attlist, elog(ERROR).
Continue normal operation.
Regression tests all still pass. There is still a problem where
duplicate columns in the list will allow the operation to succeed,
but I believe this is the only problem. If this approach is sane,
I'll clean it up later today.
comments?
cheers.
brent
--
"Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing." -- Duane Allman
