Re: proposal: more practical view on function's source code

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: more practical view on function's source code
Date: 2010-03-21 20:27:39
Message-ID: 603c8f071003211327i1991b9eevb40cfed2c830188f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 21, 2010 at 11:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-03-21 20:29:53 Re: Repeating Append operation
Previous Message Tom Lane 2010-03-21 20:07:02 Re: Proposal for Byte savings in VarBit structure