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

2010/3/21 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 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 hope so it is good way. Sure, it is personal - somebody looking on
error message and knows all - not me, and I hope so I am not the total
lost person :). I dislike solution like gdb with showing n lines
before and n lines after. And we cannot to use some external tools for
line numbering, because line numbering in our PL languages is very
specific (using line number in external editor can be confusing - I am
old dog (not for me)).

Not only for me is very difficult to identify row number from error message.

I am sure, so this way is useless for multi-hundred-line function, but
I hope so nobody write this functions (only one times I wrote very
long procedure, because I could not to use a global variables).
Optimum is about 60 lines still - and from my experience max is about
200 lines and don't forget - there is a pager.

Regards
Pavel Stehule

>
>                        regards, tom lane
>