Re: Re: [patch] Include detailed information about a row failing a CHECK constraint into the error message

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Nov 10, 2011 at 5:40 AM, Jan Kundrt <jkt(at)flaska(dot)net> wrote:
>> Would you object to a patch which outputs just the first 8kB of each
>> column? Having at least some form of context is very useful in my case.

> Well, if we're going to try to emit some context here, I'd suggest
> that we try to output only the columns implicated in the CHECK
> constraint, rather than the whole tuple.

I think that's likely to be impractical, or at least much more trouble
than the feature is worth. Also, if you might emit only a subset of
columns, then you have to label them, a la the FK error messages:
Key (x,y,z) = (this,that,theother)
That's going to make the line length problem worse not better.

I concur with just length-limiting the dumped values, and in fact would
prefer a limit much more draconian than 8K. Don't we limit the key
lengths to 1K or so in FK and unique-key messages? If the goal is to
identify the problematic line, I would think that a few dozen bytes per
column would be plenty.

> I'm not sure whether
> emitting only a certain amount of output (either total, or for each
> column) can be made to work nicely, or whether the feature overall is
> something we want. It seems like a trade-off between possibly useful
> context and possibly annoying log clutter, and I guess I don't have a
> strong opinion on which way to go with it.

I agree with Jan that this is probably useful; I'm pretty sure there
have been requests for it before. We just have to make sure that the
length of the message stays in bounds.

One tip for keeping the length down: there is no value in repeating
information from the primary error message, such as the name of the
constraint.

regards, tom lane