Re: proposal - structured funcid and lineno as new fields in error message
От | Jim Nasby |
---|---|
Тема | Re: proposal - structured funcid and lineno as new fields in error message |
Дата | |
Msg-id | 6B7DF4CF-2DAA-4147-ABE0-5B5FE6DB4524@decibel.org обсуждение исходный текст |
Ответ на | Re: proposal - structured funcid and lineno as new fields in error message (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
On Mar 29, 2010, at 11:47 AM, Pavel Stehule wrote: > 2010/3/29 Tom Lane <tgl@sss.pgh.pa.us>: >> Pavel Stehule <pavel.stehule@gmail.com> writes: >>> can we add well structured information about function id and lineno to >>> ErrorData? >> >> The idea that I was toying with was to report the function OID and line >> number, which might as well be two separate fields rather than messing >> around with anything "structured". >> >> The OID might be a bit inconvenient from the client side, but the >> trouble with trying to do more is that constructing a complete function >> descriptor will require catalog lookups, which is exactly what you don't >> want to be doing in an already-failed transaction. (We just fixed some >> bugs along that line :-() >> >> In any case, the real problem we have is not so much that we lack error >> message fields: the messages we emit for plpgsql syntax errors are quite >> complete already. The work that is needed is to provide that same >> infrastructure for run-time errors. > > I thinking about it as some tool for some admin sw. But it is little > bit more complex than I though :(. More times we doesn't need oid of > really last function - mostly will be some C function - so we have to > have some like stack. I understand so we have to do rollback before > any using of oid. But I have to do it in all cases - only oid is > useless, we need source code - so rollback is necessary. These > information can exists together with current informations - like show > some for fast info before rollback and show more detailed info after > rollback. Some parts of error data are saved before rollback - but it > is task for client. On a possibly related note, Alvaro did some work on a backtrace function a while ago, though I don't have it handy rightnow. -- Jim C. Nasby, Database Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: