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
Show quoted text
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 right now.
--
Jim C. Nasby, Database Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net