Re: syntax error position "CREATE FUNCTION" bug fix
От | Tom Lane |
---|---|
Тема | Re: syntax error position "CREATE FUNCTION" bug fix |
Дата | |
Msg-id | 11594.1079639527@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: syntax error position "CREATE FUNCTION" bug fix (Fabien COELHO <coelho@cri.ensmp.fr>) |
Список | pgsql-patches |
Fabien COELHO <coelho@cri.ensmp.fr> writes: >> But it cannot (easily) match it up with the *original input* > Sure. Even the parser in the backend cannot do it, that's the problem!;-) We *can* do it, it's just a matter of the pain level. For instance we could have the main lexer save aside an indication of the number of quoting characters it discarded at each position. The problem in my mind is to not put a heavy overhead on the main lexing path for information that will only get used in an error case. I was toying with the idea of having the CREATE FUNCTION error callback go back to the original command string (which I believe is now always saved in the Portal, and certainly could be if it isn't) and re-parse it using a slower variant of the lexer that keeps this info. Not sure what all is involved in that approach, but in principle this would let us meet the original design goal without any overhead except in the error case. > Would you accept a "it works sometimes, but it may be wrong others" hack? I think it'd be okay if it gets the common cases right and doesn't generate lies in the cases it can't get right. Also, I think it might be an acceptable compromise to give the position correctly only when the function body is quoted using dollar-quoting. (Everybody's gonna be using dollar quoting to write their functions in 7.5, right? ;-)) In that case it is trivial to convert the "inside" syntax error offset to an offset in the original string literal, and you only have to know the position of that literal in the original command to finish up. BTW, it's worth pointing out that the client will have to special-case the situation where a CONTEXT entry is present anyhow, since that most likely means that the syntax error is inside some function called by the query, and not in the query itself. So the hack in psql doesn't go away in any case; all that we do differently is not send CONTEXT from the SQL function parse error callback if we are able to convert the syntax error offset to something relative to the original command. (One could envision a really smart client pulling back the text of the function identified by the topmost CONTEXT entry and putting the cursor on that --- of course this would have to be in a popup window not the original query, but it's doable in principle.) >> My idea of a GUI syntax error report is something that puts my editing >> cursor in the right place. > Thus you decided that you prefer that NO interface should be able to show > the correct position, rather than having at least one to do it, and other > being able to display something, because you decided that the only place > to show something in a GUI is in the initial window or never. No, I say that we shouldn't put in a kluge that gets it sort-of right in a simple interface and makes it impossible for better interfaces to get it really right. I think we can do better than that. regards, tom lane
В списке pgsql-patches по дате отправления: