Re: proposal - structured funcid and lineno as new fields in error message

On Mar 29, 2010, at 11:47 AM, Pavel Stehule wrote:
> 2010/3/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net