Re: syntax error position "CREATE FUNCTION" bug fix

Dear Tom,

> > Please find attached a patch to fix the "CREATE FUNCTION" syntax error
> > position bug I reported a few days ago.
>
> This strikes me as much too intrusive to be worthwhile ... the problem
> is simply not important enough to justify a protocol change.

Then I can suggest to happend the string after the position.
NO protocol change, but the convention that the string is shown after
the position. Small difference, I sent a proposal later.

> Moreover, I don't like the proposed protocol change anyway. This
> approach only solves the problem for psql-like error reporting, namely
> clients that are going to regurgitate a string in their error message
> and aren't very picky about whether that string really matches the
> original input. One of the design goals for the error reporting feature
> is that GUI-type clients should be able to mark syntax error positions
> by highlighting in the original input window. This proposal abandons
> that goal.

I cannot see your point.

Any GUI can take advantage of the returned string to show it in a window
with fancy colors and do any hilighting around the position.

I've implemented the stuff for psql (with your help btw), but I cannot see
why it couldn't be used with other interfaces?

The issue is that the error position is not enough in some cases.
I proposed the only possible fix for that, which is to provide the
missing information to the client, which will do something or nothing
about it. The current status is that the information is not available,
so nothing can be done.

Moreover, I had problems with syntax errors in string-embedded queries in
the past, and this is trickier to solve, so I don't see why the error
position should not be fixed for those errors.

So my point is that I agree that the protocole should not be changed, but
I disagree that the "bug" should remain as it is because of some
principles.

Have a nice day,

--
Fabien Coelho - coelho(at)cri(dot)ensmp(dot)fr