| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | 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 15:42:46 |
| Message-ID: | 22165.1269186166@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2010-03-21 16:09:40 | Re: proposal: more practical view on function's source code |
| Previous Message | Tom Lane | 2010-03-21 15:29:01 | Re: xmlconcat (was 9.0 release notes done) |