Tom Lane wrote:
> I was wondering in particular whether it wouldn't be appropriate
> to include the same errdetail in ExecConstraints's other check,
> the one for null in not-null columns. Arguably a not-null check
> is just a slightly optimized form of a CHECK constraint, and
> anyway if you t
=?UTF-8?B?SmFuIEt1bmRyw6F0?= writes:
> Attached is a second version of this patch which keeps the size of the
> output at 64 characters per column (which is an arbitrary value defined
> as a const int, which I hope matches your style). Longer values have
> their last three characters replaced by "
Hello
>
> (And as a side note, I'm not really familiar with Postgres' internals,
> so it took me roughly six hours to arrive to a working patch from the
> very start. I'd therefore welcome pointers about the best way to achieve
> that with Postgres' string stream interface.)
>
http://www.pgsql.cz
Hi José and Robert, thanks for your time and a review. Comments below.
On 11/10/11 03:47, Robert Haas wrote:
> It does this already, without this patch. This patch is about CHECK
> constraints, not UNIQUE ones.
That's right. This is how to check what the patch changes:
jkt=> CREATE TABLE tbl (n
On 11/10/11 00:48, José Arthur Benetasso Villanova wrote:
> First, I couldn't apply it as in the email, even in REL9_0_STABLE: the
> offset doesn't look right. Which commit are your repository in?
Hi Jose, thanks for looking at the patch. It's based on
b07b2bdc570cfbb39564c8a70783dbce1edcb3d6, whi
On 11/10/11 16:05, Tom Lane wrote:
> I agree with Jan that this is probably useful; I'm pretty sure there
> have been requests for it before. We just have to make sure that the
> length of the message stays in bounds.
>
> One tip for keeping the length down: there is no value in repeating
> infor
Robert Haas writes:
> On Thu, Nov 10, 2011 at 10:05 AM, Tom Lane wrote:
>> Robert Haas 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
On Thu, Nov 10, 2011 at 10:05 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Nov 10, 2011 at 5:40 AM, Jan Kundrát 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
Robert Haas writes:
> On Thu, Nov 10, 2011 at 5:40 AM, Jan Kundrát 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
"""
What I want to find in the end is something which tells me "this row
causes the error". Unfortunately, as the new row of the table with the
constraint is not yet on disk, it doesn't really have its own ctid, and
therefore I cannot report that. (Which makes sense, obviously.)
"""
Would an erro
On 11/10/11 13:04, Robert Haas wrote:
> 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 f
On Thu, Nov 10, 2011 at 5:40 AM, Jan Kundrát 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 th
On 11/10/11 12:41, Dickson S. Guedes wrote:
>> jkt=> UPDATE tbl SET a = -a;
>> ERROR: new row for relation "tbl" violates check constraint "tbl_a_check"
>> DETAIL: New row with data (x, -10) violates check constraint "tbl_a_check".
>>
>> The last line, the detailed error message, is added by the
2011/11/10 Jan Kundrát :
> On 11/10/11 03:47, Robert Haas wrote:
>> It does this already, without this patch. This patch is about CHECK
>> constraints, not UNIQUE ones.
>
> That's right. This is how to check what the patch changes:
>
> jkt=> CREATE TABLE tbl (name TEXT PRIMARY KEY, a INTEGER CHECK
Hi José and Robert, thanks for your time and a review. Comments below.
On 11/10/11 03:47, Robert Haas wrote:
> It does this already, without this patch. This patch is about CHECK
> constraints, not UNIQUE ones.
That's right. This is how to check what the patch changes:
jkt=> CREATE TABLE tbl (n
2011/11/9 José Arthur Benetasso Villanova :
> postgres=# create table test1(id serial primary key, value text);
> NOTICE: CREATE TABLE will create implicit sequence "test1_id_seq" for
> serial column "test1.id"
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> "test1_pkey" for tab
> Hi,
> when I insert/update many rows at once using INSERT ... SELECT into a
> table which has plenty of CHECK constraints, the error message that
> Postgres returns has no indication of which row failed the constraint
> check. The attached patch tries to provide information in a similar way
> to
17 matches
Mail list logo
