Re: enhanced error fields

* Peter Geoghegan (peter@2ndquadrant.com) wrote:
> On 30 December 2012 03:32, Stephen Frost <sfrost@snowman.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