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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: proposal: more practical view on function's source code  (Dimitri Fontaine <dfontaine@hi-media.com>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: xmlconcat (was 9.0 release notes done)
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: proposal: more practical view on function's source code