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

On Thu, Nov 10, 2011 at 10:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Nov 10, 2011 at 5:40 AM, Jan Kundrát <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.

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.

I'd argue that to some degree, CHECK constraints, like UNIQUE
constraints, probably tend to be placed primarily on relatively short
columns. Now, UNIQUE constraints have a hard limitation, because a
too-large value won't fit into an index block. And certainly you
could do CHECK (document_is_valid_json(mumbleblump)). But many things
that contain large amounts of text will just be free text fields, they
won't be part of any constraint, and including them will just make
things unreadable.

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