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
|
Список | 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 по дате отправления: