Re: proposal: more practical view on function's source code - Mailing list pgsql-hackers

From Robert Haas
Subject Re: proposal: more practical view on function's source code
Date
Msg-id 603c8f071003211327i1991b9eevb40cfed2c830188f@mail.gmail.com
Whole thread Raw
In response to Re: proposal: more practical view on function's source code  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: proposal: more practical view on function's source code
List pgsql-hackers
On Sun, Mar 21, 2010 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> I understanding. But this functionality is implemented yet. My
>> motivation is to design some tool for more easy searching n. row in
>> source code (for interpretation error messages) and possibility to see
>> this row in some context.
>
> Why is this a good way to attack that?  If you think the context already
> provided in error messages isn't good enough, seems like the thing to do
> is fix the error messages.  Nobody is going to want to dump out a
> multi-hundred-line function like this in order to identify which
> statement is being fingered by an error.

I'm not sure that Pavel's idea is the right way to attack the problem,
but I don't agree with this either.  Line numbers are really the only
feasible way of identifying a position in a large function.  I usually
bring up the function source code in vi and then use j with a repeat
count to find the offending line.  It's not uncommon for me to have
various places in the function that look somewhat similar, so
expecting me to find the right place other than by the line number
would not work very well for me.

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal for Byte savings in VarBit structure
Next
From: Robert Haas
Date:
Subject: Re: Repeating Append operation