Hi Tom and Marti
Thank you so much for your respond.
The solution Tom proposed is much more better, and it will be a great
solution for clarifying many issues regarding this error.
Regards,
Maor
On 01/19/2014 10:00 PM, Tom Lane wrote:
> Marti Raudsepp <marti@juffo.org> writes:
>> On Sun, Jan 19, 2014 at 8:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> One thing that occurs to me just now is that perhaps we could report
>>> the failure as if it were a syntax error
>
>> That would be cool, if it can be made to work.
>
> Just as a five-minute proof-of-concept hack, attached is a patch that
> makes varchar() report an error position if it can get one. This is
> *very* far from being production quality --- debug_query_string is the
> wrong thing to rely on in general, and we'd certainly want to encapsulate
> the logic rather than have individual functions know about how to do it.
> But here's some testing that shows that the idea seems to have promise
> from a usability standpoint:
>
> regression=# create table test (f1 varchar(10), f2 varchar(5), f3 varchar(10));
> CREATE TABLE
>
> regression=# insert into test values ('a', 'b', 'foobar');
> INSERT 0 1
>
> regression=# insert into test values ('foobar', 'foobar', 'foobar');
> ERROR: value too long for type character varying(5)
> LINE 1: insert into test values ('foobar', 'foobar', 'foobar');
> ^
>
> regression=# update test set f2 = f3 where f1 = 'a';
> ERROR: value too long for type character varying(5)
> LINE 1: update test set f2 = f3 where f1 = 'a';
> ^
>
> The first error case points out a limitation of relying on the contents of
> the string to figure out where your problem is. The error-cursor approach
> has its own limitations, of course; for instance the second case might not
> be thought to be all that helpful.
Yes, but in this case you will know specifically which column is the
problematic one.
The highlight of your approach gains much more benefit when
updating/inserting multiple values in one update/insert command.
>
> regards, tom lane
>