Re: Syntax error reporting (was Re: [PATCHES] syntax error position "CREATE FUNCTION" bug fix)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Syntax error reporting (was Re: [PATCHES] syntax error position "CREATE FUNCTION" bug fix)
Дата
Msg-id 29795.1079968321@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Syntax error reporting (was Re: [PATCHES] syntax error position  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: Syntax error reporting (was Re: [PATCHES] syntax error  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.fr> writes:
>>> More over, I have other ideas for CONTEXT, which should really be a stack.
>> It already is a stack.

> Ok, I agree that there is a "push", but I'm still looking fot the "pop".

> Maybe I missed something, but it seemed to me that strings are appended
> on to the other, and there is no way back.

But the string list is not constructed until the error actually occurs.
You don't need a pop at that point --- the call stack is what it is.

I think you are imagining that outer-level context hooks should be able
to editorialize on what inner-level ones said (or perhaps vice versa?)
but I honestly cannot think of a valid use-case for that.

> What I would have looked for, is a stack on which functions could push
> and pop informations as they want, so that the stack would be always
> available for any error or warning or debug trace down the callgraph.

Look at the existing examples of adjusting the error_context_stack.
They already do all that, they just don't bother to compute the error
strings unless actually needed.  I'm not willing to push very much cost
into the non-error path of control when there's no visible payoff.
        regards, tom lane


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCHES] UnixWare/CVS Tip/initdb.c needs to use threads
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Custom format for pg_dumpall