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

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

In response to

Responses

Browse pgsql-hackers by date

  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)