[2002-01-13 12:33] Brent Verner said:
| [2002-01-13 11:41] Tom Lane said:
| | Brent Verner <brent@rcfile.org> writes:
| | > In CopyFrom, if attlist present, create Form_pg_attribute* ordered
| | > same as attlist.
| |
| | Doesn't seem like this can possibly work as-is. The eventual call to
| | heap_formtuple must supply the column values in the order expected
| | by the table, but I don't see you remapping from input-column indices to
| | table-column indices anywhere in the data processing loop.
|
| yup. back to the drawing board ;-)
I fixed this by making an int* mapping from specified collist
position to actual rd_att->attrs position.
| | Also, a reasonable version of this capability would allow the input
| | column list to be just a subset of the table column list; with the
| | column default expressions, if any, being evaluated to fill the missing
| | columns. This would answer the requests we keep having for COPY to be
| | able to load a table containing a serial-number column.
|
| right.
I'm still a bit^W^W lost as hell on how the column default magic
happens. It appears that in the INSERT case, the query goes thru
the planner and picks up the necessary Node* representing the
default(s) for a relation, then later evaluates those nodes if
not attisset.
Should I be looking to call ExecEvalFunc(stringToNode(adbin),ec,&rvnull,NULL);
when an attr is not specified and it has a default? Or is there
a more straightforward way of getting the default for an att?
(I sure hope there is ;-)
thanks. 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