Re: Problem reloading regression database
От | Brent Verner |
---|---|
Тема | Re: Problem reloading regression database |
Дата | |
Msg-id | 20020113153019.GA874@rcfile.org обсуждение исходный текст |
Ответ на | Re: Problem reloading regression database (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Problem reloading regression database
|
Список | pgsql-hackers |
[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
Вложения
В списке pgsql-hackers по дате отправления: