Re: Add value to error message when size extends

Hi,

Many thanks for the prompt response and the suggestions!

So, regarding the issue of "production quality" you've mentioned,
we understand there are two remaining matters to address:
1. debug_query_string:
As we can't rely on this flag, is there any alternative we can rely on?
2. encapsulation:
Is there any "utility file" we could extract the logic to?
Or, any other functions that are used for encapsulation mechanism?

Thanks!
Daniel

----- Original Message -----
> From: "Maor Lipchuk" <mlipchuk(at)redhat(dot)com>
> To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Marti Raudsepp" <marti(at)juffo(dot)org>
> Cc: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>, "Daniel Erez" <derez(at)redhat(dot)com>
> Sent: Monday, January 20, 2014 2:32:57 AM
> Subject: Re: [HACKERS] Add value to error message when size extends
>
> 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(at)juffo(dot)org> writes:
> >> On Sun, Jan 19, 2014 at 8:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
> >
>
>