2011/7/28 Florian Pflug :
> On Jul27, 2011, at 23:20 , Pavel Stehule wrote:
>> this is a refreshed patch. Only constraints and RI is supported now.
>> There is about 1000 ereport calls, where a enhanced diagnostics should
>> be used, but probably we don't modify all in one time.
>
> I wonder if it
On Jul27, 2011, at 23:20 , Pavel Stehule wrote:
> this is a refreshed patch. Only constraints and RI is supported now.
> There is about 1000 ereport calls, where a enhanced diagnostics should
> be used, but probably we don't modify all in one time.
I wonder if it wouldn't be better to have somethi
Excerpts from Pavel Stehule's message of lun jul 18 16:02:43 -0400 2011:
> 2011/7/18 Tom Lane :
> > which suggests that it might be meant *only* for use with
> > INSUFFICIENT_PRIVILEGE errors that are thrown due to a column ACL.
> > We can probably extend that to some other syntax errors, like unk
"Kevin Grittner" writes:
> Josh Berkus wrote:
>> I'm less concerned about the standard here and more concerned
>> about what helps our users. Having column names for an FK error
>> is *extremely* useful for troubleshooting, particularly if the
>> database has been upgraded from the 7.4 days and
Josh Berkus wrote:
> I'm less concerned about the standard here and more concerned
> about what helps our users. Having column names for an FK error
> is *extremely* useful for troubleshooting, particularly if the
> database has been upgraded from the 7.4 days and has non-useful FK
> names like
Tom,
> Either one. They both have the potential to reference more than one
> column, so if the committee had meant errors to try to identify the
> referenced columns, they'd have put something other than COLUMN_NAME
> into the standard. They didn't.
I'm less concerned about the standard here an
Pavel Stehule writes:
> so for example, NULL or DOMAIN constraints doesn't affect a
> COLUMN_NAME? These constraints has no name.
Well, the executor's NOT NULL tests could certainly be extended to emit
COLUMN_NAME --- I don't see any logical or implementation problem with
that, even if it seems t
2011/7/18 Tom Lane :
> Pavel Stehule writes:
>> 2011/7/18 Tom Lane :
Are we talking about FK constraints here, or CHECK contstraints?
>
>>> Either one. They both have the potential to reference more than one
>>> column, so if the committee had meant errors to try to identify the
>>> referenc
Pavel Stehule writes:
> 2011/7/18 Tom Lane :
>>> Are we talking about FK constraints here, or CHECK contstraints?
>> Either one. They both have the potential to reference more than one
>> column, so if the committee had meant errors to try to identify the
>> referenced columns, they'd have put s
2011/7/18 Tom Lane :
> Josh Berkus writes:
>> Tom,
>>> No, I don't. You're adding complication to solve a problem that doesn't
>>> need to be solved. The standard says to return the name of the
>>> constraint for a constraint-violation failure. It does not say anything
>>> about naming the asso
Josh Berkus writes:
> Tom,
>> No, I don't. You're adding complication to solve a problem that doesn't
>> need to be solved. The standard says to return the name of the
>> constraint for a constraint-violation failure. It does not say anything
>> about naming the associated column(s). COLUMN_NA
Tom,
> No, I don't. You're adding complication to solve a problem that doesn't
> need to be solved. The standard says to return the name of the
> constraint for a constraint-violation failure. It does not say anything
> about naming the associated column(s). COLUMN_NAME is only supposed to
> b
Pavel Stehule writes:
> There is only one issue, that should be solved first. I introduced non
> standard diagnostics field "column_names", because there is not
> possible get "column_name" value for check constraints now. A correct
> implementation of COLUMN_NAME field needs a explicit relation
Hello Tom,
Thank you for review
I am thinking, so your comment is clean and I'll respect it in new version.
There is only one issue, that should be solved first. I introduced non
standard diagnostics field "column_names", because there is not
possible get "column_name" value for check constraint
Pavel Stehule writes:
> I am sending a updated patch
I looked over this patch a bit. I guess my main concern about it
is that the set of items to be reported seems to have been made up on
a whim. I think that we ought to follow the SQL standard, which has a
pretty clearly defined set of additio
2011/6/21 Steve Singer :
> On 11-06-20 03:44 PM, Pavel Stehule wrote:
>
> Hello
>
> You need to update config.sgml at the same time you update this format.
> You need to append a "," after application name but before constraintName.
> As it stands the CSV log has something like:
> .nbtinsert.c:
On 11-06-20 03:44 PM, Pavel Stehule wrote:
Hello
You need to update config.sgml at the same time you update this format.
You need to append a "," after application name but before constraintName.
As it stands the CSV log has something like:
.nbtinsert.c:433","psql""a_pkey","public","a","a"
Hello
I am sending a updated patch
>
> Coding Review
> -
>
>
> In tupdesc.c
>
> line 202 the existing code is performing a deep copy of ConstrCheck. Do you
> need to copy nkeys and conkey here as well?
>
> Then at line 250 ccname is freed but not conkey
>
fixed
>
> postgres_ext
Excerpts from Pavel Stehule's message of dom jun 19 06:51:13 -0400 2011:
> Hello
>
> 2011/6/19 Steve Singer :
> > On 11-06-08 04:14 PM, Pavel Stehule wrote:
> > nbtinsert.c
> >
> > pg_get_indrelation is named differently than everything else in this file
> > (ie _bt...). My guess is that this fu
On Sun, 19 Jun 2011, Pavel Stehule wrote:
Maybe there is second issue (little bit - performance - you have to
call a output function), But I agree, so this information is very
interesting and can help.
I am concerned about the performance impact of doing that. Not all
constraints are on int4
2011/6/19 Florian Pflug :
> On Jun19, 2011, at 14:03 , Pavel Stehule wrote:
>> 2011/6/19 Florian Pflug :
>>> Speaking as someone who's wished for the feature that Pavel's patch provides
>>> many times in the past - shouldn't there also be a field containing the
>>> offending value? If we had that,
On Jun19, 2011, at 14:03 , Pavel Stehule wrote:
> 2011/6/19 Florian Pflug :
>> Speaking as someone who's wished for the feature that Pavel's patch provides
>> many times in the past - shouldn't there also be a field containing the
>> offending value? If we had that, it'd finally be possible to tran
2011/6/19 Florian Pflug :
> On Jun19, 2011, at 05:10 , Steve Singer wrote:
>> On 11-06-18 06:36 PM, Steve Singer wrote:
>>> On 11-06-08 04:14 PM, Pavel Stehule wrote:
>>>
>>> Here is my review of this patch
>>>
>>> Submission Review:
>>>
>>> The patch applies cleanly agains
On Jun19, 2011, at 05:10 , Steve Singer wrote:
> On 11-06-18 06:36 PM, Steve Singer wrote:
>> On 11-06-08 04:14 PM, Pavel Stehule wrote:
>>
>> Here is my review of this patch
>>
>> Submission Review:
>>
>> The patch applies cleanly against master
>> The patch does not inc
2011/6/19 Steve Singer :
> On 11-06-18 06:36 PM, Steve Singer wrote:
>>
>> On 11-06-08 04:14 PM, Pavel Stehule wrote:
>>
>> Here is my review of this patch
>>
>> Submission Review:
>>
>> The patch applies cleanly against master
>> The patch does not include any documentatio
Hello
2011/6/19 Steve Singer :
> On 11-06-08 04:14 PM, Pavel Stehule wrote:
>>
>> Hello
>>
>> Attached patch implements a new erros's fields that describes table,
>> colums related to error. This enhanced info is limited to constraints
>> and RI.
>>
>
...
>
> I think that both the CONSTRAINT, an
On 11-06-18 06:36 PM, Steve Singer wrote:
On 11-06-08 04:14 PM, Pavel Stehule wrote:
Here is my review of this patch
Submission Review:
The patch applies cleanly against master
The patch does not include any documentation updates (see note below
to update config.sgml)
On 11-06-08 04:14 PM, Pavel Stehule wrote:
Hello
Attached patch implements a new erros's fields that describes table,
colums related to error. This enhanced info is limited to constraints
and RI.
Here is my review of this patch
Submission Review:
The patch applies cl
Hello
Attached patch implements a new erros's fields that describes table,
colums related to error. This enhanced info is limited to constraints
and RI.
example:
postgres=# create table omega(a int unique not null check (a > 10));
NOTICE: 0: CREATE TABLE / UNIQUE will create implicit index
29 matches
Mail list logo
