On 1/29/13 6:40 PM, Tom Lane wrote:
I wrote:
>Over in the thread about enhanced error fields, I claimed that
>"constraints are uniquely named among those associated with a table,
>or with a domain". But it turns out that that ain't necessarily so,
>because the code path for index constraints do
On 1/28/13 6:25 PM, Tom Lane wrote:
I think we need to tighten this down by having index-constraint creation
check for conflicts with other constraint types. It also seems like it
might be a good idea to put in a unique index to enforce the intended
lack of conflicts --- note that the existing i
I wrote:
> Over in the thread about enhanced error fields, I claimed that
> "constraints are uniquely named among those associated with a table,
> or with a domain". But it turns out that that ain't necessarily so,
> because the code path for index constraints doesn't pay any attention
> to pre-ex
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Geoghegan writes:
> > I can see the case for fixing this, but I don't feel that it's
> > particularly important that constraints be uniquely identifiable from
> > the proposed new errdata fields.
>
> I think that we'll soon be buried in gripes if the
> Tom Lane Wrote:
> Peter Geoghegan writes:
> > On 29 January 2013 00:25, Tom Lane wrote:
> > I can see the case for fixing this, but I don't feel that it's
> > particularly important that constraints be uniquely identifiable from
> > the proposed new errdata fields.
>
> I think that we'll soon
On Mon, Jan 28, 2013 at 10:23 PM, Tom Lane wrote:
> I think that we'll soon be buried in gripes if they're not. Pretty much
> the whole point of this patch is to allow applications to get rid of
> ad-hoc, it-usually-works coding techniques. I'd argue that not checking
> the entire constraint ide
Peter Geoghegan writes:
> On 29 January 2013 00:25, Tom Lane wrote:
>> Of course this wouldn't be material for back-patching, but it seems to
>> me there's still time to fix this for 9.3, and we should do so if we
>> want to claim that the enhanced-errors patch uniquely identifies
>> constraints.
On 29 January 2013 00:25, Tom Lane wrote:
> Of course this wouldn't be material for back-patching, but it seems to
> me there's still time to fix this for 9.3, and we should do so if we
> want to claim that the enhanced-errors patch uniquely identifies
> constraints.
I can see the case for fixing
Over in the thread about enhanced error fields, I claimed that
"constraints are uniquely named among those associated with a table,
or with a domain". But it turns out that that ain't necessarily so,
because the code path for index constraints doesn't pay any attention
to pre-existing check constr
