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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jan Kundrát <jkt@flaska.net>, pgsql-hackers@postgresql.org
Date: 2011-11-10T15:37:41Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Don't assume that a tuple's header size is unchanged during toasting.

Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Nov 10, 2011 at 10:05 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> 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.

> Depends.  A lot of CHECK constraints may only reference one column:
> CHECK (a > 0).  The whole record is likely to be a lot longer than
> (a)=(-32768), and frankly tuples without column names aren't that
> readable anyway.

Well, the other concern here is: how much context does it take to
identify the problematic row?  It's entirely likely that showing only
the value of "a" isn't enough to solve the user's problem anyhow.
So I think the argument for showing a subset of columns is quite weak.

			regards, tom lane