>
> 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.
depends on perspective - lines of error context are taken by same
mechanism and some other fields from ErrorData too.
I have not strong opinion if last implementation is the best - but I
am sure about context. Developer usually should to know, where
exception was created but interesting is position in custom code - so
it usually different function than function that raises exception. If
I understand you, we have a fields that has behave that you expected -
filename and funcname. And I have not used these fields for
application programming.
Regards
Pavel
>
> [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
