On 28 December 2012 15:57, Tom Lane <t...@sss.pgh.pa.us> wrote: > I don't think that part's been agreed to at all; it seems entirely > possible that it'll get dropped if/when the patch gets committed. > I'm not convinced that having these fields in the log is worth > the compatibility hit of changing the CSV column set.
I am willing to let that go, because it just doesn't seem important to me. I just thought that if we were going to break compatibility, we might as well not hold back on the inclusion of fields. I'm not sure where this leaves the regular log. Pavel wants to remove that, too. I defer to others. Now, as to the question of whether we need to make sure that everything is always fully qualified - I respectfully disagree with Stephen, and maintain my position set out in the last round of feedback [1], which is that we don't need to fully qualify everything, because *for the purposes of error handling*, which is what I think we should care about, these fields are sufficient: + column_name text, + table_name text, + constraint_name text, + schema_name text, If you use the same constraint name everywhere, you might get the same error message. The situations in which this scheme might fall down are too implausible for me to want to bloat up all those ereport sites any further (something that Stephen also complained about). I think that the major outstanding issues are concerning whether or not I have the API here right. I make explicit guarantees as to the availability of certain fields for certain errcodes (a small number of "Class 23 - Integrity Constraint Violation" codes). No one has really said anything about that, though I think it's important. I also continue to think that we shouldn't have "routine_name", "routine_schema" and "trigger_name" fields - I think it's wrong-headed to have an exception handler magically act on knowledge about where the exception came from that has been baked into the exception - is there any sort of precedent for this? Pavel disagrees here. Again, I defer to others. [1] Post of revision "eelog4.diff": http://archives.postgresql.org/message-id/caeylb_um9z8vitjckaogg2shab1n-71doznhj2pjm2ls96q...@mail.gmail.com -- 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
