Re: enhanced error fields

On 28 December 2012 15:57, Tom Lane <tgl@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-71dozNhj2PJm2Ls96QVPg@mail.gmail.com
-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services