Re: [Review] Include detailed information about a row failing a CHECK constraint into the error message - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [Review] Include detailed information about a row failing a CHECK constraint into the error message
Date
Msg-id 23481.1322589115@sss.pgh.pa.us
Whole thread Raw
In response to [Review] Include detailed information about a row failing a CHECK constraint into the error message  (Royce Ausburn <royce.ml@inomial.com>)
Responses Re: [Review] Include detailed information about a row failing a CHECK constraint into the error message
List pgsql-hackers
Royce Ausburn <royce.ml@inomial.com> writes:
> One comment I have on the output is that strings are not in quotes.  It's a little jarring, but might not be that big
adeal.  A contrived case that is pretty confusing:
 

> test=#   insert into test select 1, 2, '3, 4', 4;
> ERROR:  new row for relation "test" violates check constraint "test_b_check"
> DETAIL:  Failing row: (1, 2, 3, 4, 4).

> A select inserting 4 columns seemingly results in a 5 column row ;)

FWIW, I don't think it's the province of this patch to resolve this
issue, since as Jan noted, unique-index violation reports do it the same
way.  I think for the moment we should have it emit the same unquoted
format that BuildIndexValueDescription does, with the exception of
truncating long field values.  (BuildIndexValueDescription doesn't
currently worry about that since long values are much less likely in
index entries; though perhaps we should make it do so.)

If we decide that it's important to quote or escape values reported in
these messages, that should be the subject of a separate patch that also
changes BuildIndexValueDescription.  But personally I doubt it's
necessary.

In short, I'm inclined to go ahead and apply this patch, after a bit of
cleanup to make it match our house style better and not break multibyte
characters.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: patch for type privileges
Next
From: Alvaro Herrera
Date:
Subject: Re: review: CHECK FUNCTION statement