Re: syntax error position "CREATE FUNCTION" bug fix

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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