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