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
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 |