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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: proposal: more practical view on function's source code
Дата
Msg-id 603c8f071003211327i1991b9eevb40cfed2c830188f@mail.gmail.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>)
Список pgsql-hackers
On Sun, Mar 21, 2010 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pavel Stehule <pavel.stehule@gmail.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.

I'm not sure that Pavel's idea is the right way to attack the problem,
but I don't agree with this either.  Line numbers are really the only
feasible way of identifying a position in a large function.  I usually
bring up the function source code in vi and then use j with a repeat
count to find the offending line.  It's not uncommon for me to have
various places in the function that look somewhat similar, so
expecting me to find the right place other than by the line number
would not work very well for me.

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Proposal for Byte savings in VarBit structure
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Repeating Append operation