Лейте COPY в промежуточную таблу-корзину с полями text, а оттуда уже осуществляйте заливку с разбором значений и CAST-ингом.


_________
Подумал было, что RULE на INSERT (с разбором и подменой мусора умолчательными значениями) может помочь (если COPY не обходит RULE) обойтись без промежуточной корзинки. И если такое RULE допустимо "напостоянку" - т.е. не только для вливки данных (в этом случае можно бы было поробовать RULE на view) - АН ФИХ - COPY can only be used with plain tables, not with views). и даже: COPY FROM will invoke any triggers and check constraints on the destination table. However, it will not invoke rules.
Т.ч RULE отпадает.

ГАГН 2
а можно поподробнее остановиться на моменте разбора значений?

не понял, в чем проблема. Если в том, чтобы произвести CAST от всех подходящих значений text в требуемый тип - так при написании процедуры упирайте на SQL а не на plpgsql и отлаживайте куски - оно вам само сообщит, есть ли CAST от text к тому типу, к какому хотите. Если нет - сделайте цепочку кастов через промежуточные типы. (или напишите свои ф-ии).


Если же вы хотите обработать ошибку, боюсь ни в SQL транзакции, ни в plpgsql функции вы этого сегодня не сделаете:
PostgreSQL 7.4beta4 Documentation
Chapter 39. PL/pgSQL - SQL Procedural Language

Thus, the only thing PL/pgSQL currently does when it encounters an abort during execution of a function or trigger procedure is to add some fields to the message telling in which function and where (line number and type of statement) the error happened. The error always stops execution of the function.
я вижу только одну главу в документации, посвященную Error Handling PostgreSQL 7.4beta4 Documentation
Chapter 30. ECPG - Embedded SQL in C
--------------------------------------------------------------------------------

30.9. Error Handling
А SQL транзакция однозначно потребует RallBack после первой же ошибки (не понимаю, почему тогда серверу не делать RallBack автоматом с закрытием транзакции и выдачей соответственного сообщения - чё ждать то, когда все остальное все равно запрещено? Удизм какой-то академический...)



Т.е. , в итоге, вы должны написать что-то вида
причем так, чтобы нигде не могло возникнуть ошибок при вставке.
Если не уверены в том, что перекрыли все возиможные источники ошибок при приведении данных (например констрайнты могут меняться), а вставлять хотя бы то, что вставится надо, то выход - в построчной вставке из любого внешнего инструмента, позволяющего обработку ошибок (т.е. INSERT INTO делаете для строки, и независимо от того вставилась/не вставилась - вставляете следущую, а "не вставку" суете в лог, для ручного разбора). Аналогом этого внешнего (по отношению к SQL) инструмента видимо может служить и C (не пользовался).