From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jan Kundrát <jkt(at)flaska(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: [patch] Include detailed information about a row failing a CHECK constraint into the error message |
Date: | 2011-11-10 12:04:52 |
Message-ID: | CA+TgmoaQcsNcMyP5-HMjx1CTY1CALocFCZQ+aonV5C77Y3QZ8Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 10, 2011 at 5:40 AM, Jan Kundrát <jkt(at)flaska(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Kundrát | 2011-11-10 13:40:14 | Re: Re: [patch] Include detailed information about a row failing a CHECK constraint into the error message |
Previous Message | Nikhil Sontakke | 2011-11-10 12:00:17 | Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers |