Re: enhanced error fields

* Peter Geoghegan (peter(at)2ndquadrant(dot)com) wrote:
> On 30 December 2012 03:32, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > Err. I intended to say "I really don't think what I sketched out, or
> > something similar, would be that unlikely to happen", or something along
> > those lines. Apologies for the confusion.
>
> Almost anything can be misused.

I agree, almost anything can be. The 'misuse' in this case, however, is
in expecting the information returned to be useful in a deterministic
and consistent manner, as it's being returned in a programmatic fashion.

> If you're going to insist that I hack a bunch of mechanism into this
> patch so that the user can unambiguously identify each constraint
> object, I'll do that.

This is the part that I'm having trouble wrapping my head around- what's
the additional complexity here? If we have the OID of the constraint,
we should be able to unambiguoulsy return information which allows a
user to get back to that specific constraint and OID.

> However, that's more code, and more complexity,
> that will have to be documented, for just next to no practical benefit
> that I can see.

I've certainly seen cases where constraints are duplicated by name
across schemas. I would imagine it could happen across tables in the
same schema also. I just don't like this notion of returning something
ambiguous to the user and worry that they'd accept it as deterministic
and dependable, regardless of the documentation. There's a certain
amount of "read the docs, but also look at what information you really
get back", which I think is, in general, a good thing, but it does mean
individuals might come to believe that they can depend on the constraint
name being unique in all cases.

As a side-note, I've recently run into more cases than I care to think
about where the 63-character limit on constraint names has been a
problem- because we're trying to ensure that we create an unambiguous
constraint name, and that's *with* various name shortening techniques
being used. The discussion about having longer values possible for the
'name' data type was on a different thread and should probably stay
there, but I bring it up because it has some impact on the possibility
of name collisions which is relevent to this discussion.

Thanks,

Stephen