Re: enhanced error fields

On 29 December 2012 20:49, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> In the end, I may agree with you- the patch is a nice idea, but it needs
> more to be a complete and working solution and providing something that
> only gets people half-way there would result in developers hacking
> things together which will quitely break when they least expect it.

I certainly wouldn't go that far. I think that 95% of the value that
could be delivered by this sort of thing will be realised by
committing something that is along the lines of what we have here
already. All I really want is to give users a well-principled way of
getting a constraint name within their error handler, so that they can
go do something in their application along the lines of displaying a
custom error message in the domain of the application and/or error
handler, not the domain of the database. That's it.

Ascertaining the identity of the object in question perfectly
unambiguously, so that you can safely do something like lookup a
comment on the object, seems like something way beyond what I'd
envisioned for this feature. Why should the comment be useful in an
error handler anyway? At best, that seems like a nice-to-have extra to
me. The vast majority are not even going to think about the ambiguity
that may exist. They'll just write:

if (constraint_name == "upc")
MessageBox("That is not a valid barcode.");

If it isn't the same constraint object as expected - if they have
multiple schemas with the same object definitions, are they likely to
care? We'll never promise that constraint_name is unambiguous, and in
fact will warn that it may be ambiguous.

It seems like what you're really looking for is a way of effectively
changing the error message to a user-defined error message using some
kind of DDL against a constraint object, without doing anything
special in a handler. That would be less flexible, but more automated,
and would probably entail using placeholders in our custom message
that get expanded (as with FK constraint violations - *what* key was
violated?). That has its appeal, but I don't see that it's something
that we need to do first.

Don't get me wrong - I think it's quite possible to pin down a way of
unambiguously identifying constraint objects as they appear here. I
just think that it isn't worth the effort to maintain the code in
Postgres, and in particular, I think people will not care about any
ambiguity, and even if they do, they could easily misunderstand the
exact rules. The right thing to do is not have multiple constraints
with the same name in flight within the same place that do different
things.

--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services