Maor Lipchuk <mlipchuk@redhat.com> writes:
> We have encountered an issue when executing an insert command,
> when one of the values' length was bigger than the column size limitation.
> the error message which been displayed was "value too long for type char..."
> but there was no indication which value has exceeded the limited size.
> (See bug #8880)
> Attached is a WIP patch which attend to make the message clearer.
This sort of thing has been proposed before ...
We have a message style guideline that says that primary error messages
should fit on "one line", which is generally understood to mean maybe
80 characters. Complaining about a too-long varchar string in this style
seems practically guaranteed to violate that. More, putting the string
contents before the meat of the message is the worst possible choice if
a client user interface decides to truncate the message. And if the
string were *really* long, say in the millions of characters, it's not
unlikely that this would end up causing the message to get replaced by
"out of memory", which is totally counterproductive.
You could avoid the first two of those objections by putting the string
contents into a DETAIL message; but not the third one.
Aside from that, it's less than clear whether this approach would actually
help much: maybe the string is readily identifiable as to which column
it's meant for, and maybe not. People have speculated about ways to
name the target column in the error report, which would probably be
far more useful; but it's not real clear how to do that in our system
structure.
One thing that occurs to me just now is that perhaps we could report
the failure as if it were a syntax error, that is with an error cursor
pointing to where in the triggering SQL query the coercion is being done.
(Years ago this would not have been possible because we didn't always
keep around the query text until runtime, but I think we do now.)
It would take some work to make that happen, and I'm not sure it would
really resolve the usability problem, but it seems worth proposing.
An advantage is that over time such a facility could be extended to
run-time errors happening in any function not just this particular one.
regards, tom lane
