2010/3/21 Tom Lane <t...@sss.pgh.pa.us>: > Pavel Stehule <pavel.steh...@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 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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers