Re: proposal: more practical view on function's source code
От | Dimitri Fontaine |
---|---|
Тема | Re: proposal: more practical view on function's source code |
Дата | |
Msg-id | m2vdcpd0lj.fsf@hi-media.com обсуждение исходный текст |
Ответ на | Re: proposal: more practical view on function's source code (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: proposal: more practical view on function's source code
Re: proposal: more practical view on function's source code |
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > 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. Well that's true in that I've often counted lines myself for short enough procedures, and as soon as they too long I just add lots of RAISE NOTICE and build up a test-case etc. I'm not sure what better tool than what Pavel is proposing we already have, though. Sure, I should go and write a complete pgsql emacs mode with a linum-mode like feature counting lines the way PG does it, … But a simple \dfs for seeing the only the source, maybe with \dfs+ for seeing the line numbers too, would be a nice addition to psql in my view. Regards, -- dim
В списке pgsql-hackers по дате отправления: