Bruce Momjian wrote:
> The problem is that the error comes at a very low level in the code.
>
Well... If it knows the input file name and line number (and the message
looks like it does), it is hard to imagine it could not report at least
the column index in this case (I understand, that the column name is too
much to ask, but the index would, probably suffice anyway).
Well... I don't really know what is the problem with finding out which
column is empty in the single line of text, so I don't care much about
this one...
What drives me crazy though is the way it reports referential integrity
violations:
ERROR: <unnamed> referential integrity violation - key referenced from
child not found in parent
Now, is it really that hard to tell *which* value for the key was not
found?
Would be really useful to know if you are trying to insert a few hundred
thousand rows, and only one of them has a problem :-(
Dima
> ---------------------------------------------------------------------------
>
> Mike Mascari wrote:
>
>>From: "Bruce Momjian" <pgman@candle.pha.pa.us>
>>
>>>New in 7.3, you can specify an empty COPY column for an
>>
>>integer. It has
>>
>>>to be a zero or some other value.
>>
>>That's true of course (that you cannot specify an empty column
>>for an integer). But Chisel's complaint still remains; the error
>>reporting in some messages (particularly type-related errors)
>>fails to provide any concrete information as to which attribute
>>of which table caused the failure. One would have to log queries
>>to determine where the failure took place. I don't think its
>>unfair to say that other DBMS products do a better job of
>>reporting more details of the failure - schema, table,
>>attribute, etc.
>>
>>Mike Mascari
>>mascarm@mascari.com
>>
>>
>>>Chisel Wright wrote:
>>>
>>>>I like postgres, I find I get on much better with it than
>>
>>mysql.
>>
>>>>I have one really big problem with it though.
>>>>
>>>>Why is the error reporting so bad/vague for failed inserts?
>>>>
>>>> ERROR: pg_atoi: zero-length string
>>>>
>>>>No clues as to which field or piece of data it is
>>
>>complaining about.
>>
>>>>Does anyone know how to find this out?
>>
>>
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 3: if posting/reading through Usenet, please send an appropriate
>>subscribe-nomail command to majordomo@postgresql.org so that your
>>message can get through to the mailing list cleanly
>>
>
>