Re: Add value to error message when size extends - Mailing list pgsql-hackers

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
forencapsulation mechanism?
 

Thanks!
Daniel 

----- Original Message -----
> From: "Maor Lipchuk" <mlipchuk@redhat.com>
> To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Marti Raudsepp" <marti@juffo.org>
> Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>, "Daniel Erez" <derez@redhat.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@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
> > 
> 
>