On 29 December 2012 20:49, Stephen Frost <sfr...@snowman.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers