From: | Dimitri Fontaine <dfontaine(at)hi-media(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 17:51:52 |
Message-ID: | m2vdcpd0lj.fsf@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2010-03-21 18:00:31 | Re: proposal: more practical view on function's source code |
Previous Message | Andrew Dunstan | 2010-03-21 17:07:02 | Re: xmlconcat (was 9.0 release notes done) |