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" <mlipc...@redhat.com> > To: "Tom Lane" <t...@sss.pgh.pa.us>, "Marti Raudsepp" <ma...@juffo.org> > Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>, "Daniel Erez" > <de...@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 <ma...@juffo.org> writes: > >> On Sun, Jan 19, 2014 at 8:10 PM, Tom Lane <t...@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 > > > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers