From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jan Kundrát <jkt(at)flaska(dot)net>, 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 15:37:41 |
Message-ID: | 8367.1320939461@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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:
>>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Kundrát | 2011-11-10 15:56:32 | Re: Re: [patch] Include detailed information about a row failing a CHECK constraint into the error message |
Previous Message | Tom Lane | 2011-11-10 15:30:35 | Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers |