Re: proposal - structured funcid and lineno as new fields in error message - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: proposal - structured funcid and lineno as new fields in error message
Date
Msg-id 6B7DF4CF-2DAA-4147-ABE0-5B5FE6DB4524@decibel.org
Whole thread Raw
In response to Re: proposal - structured funcid and lineno as new fields in error message  (Pavel Stehule <pavel.stehule@gmail.com>)
List 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 by date:

Previous
From: Jim Nasby
Date:
Subject: Re: inlining SQL functions
Next
From: Tom Lane
Date:
Subject: Re: global temporary tables