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

From Robert Haas
Subject Re: Re: [patch] Include detailed information about a row failing a CHECK constraint into the error message
Date
Msg-id CA+TgmoaQcsNcMyP5-HMjx1CTY1CALocFCZQ+aonV5C77Y3QZ8Q@mail.gmail.com
Whole thread Raw
In response to Re: Re: [patch] Include detailed information about a row failing a CHECK constraint into the error message  (Jan Kundrát <jkt@flaska.net>)
Responses Re: Re: [patch] Include detailed information about a row failing a CHECK constraint into the error message
Re: Re: [patch] Include detailed information about a row failing a CHECK constraint into the error message
List pgsql-hackers
On Thu, Nov 10, 2011 at 5:40 AM, Jan Kundrát <jkt@flaska.net> wrote:
> That's an interesting thought. I suppose the same thing is an issue with
> unique keys, but they tend to not be created over huge columns, so it
> isn't really a problem, right?

Pretty much.

> 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'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.

Anyone else have an opinion?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Nikhil Sontakke
Date:
Subject: Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Next
From: Jan Kundrát
Date:
Subject: Re: Re: [patch] Include detailed information about a row failing a CHECK constraint into the error message