Thread: proposal - structured funcid and lineno as new fields in error message
Hello can we add well structured information about function id and lineno to ErrorData? Actually we sending some info - but formated as string and only when Log_error_verbosity >= PGERROR_VERBOSE. I hope, so this feature can help to some interactive GUI managers as pgAdmin, and to psql too. Regards Pavel Stehule
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.
regards, tom lane
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. Regards Pavel Stehule > > regards, tom lane >
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