Re: syntax error position "CREATE FUNCTION" bug fix - Mailing list pgsql-patches

From Tom Lane
Subject Re: syntax error position "CREATE FUNCTION" bug fix
Date
Msg-id 10617.1079632605@sss.pgh.pa.us
Whole thread Raw
In response to Re: syntax error position "CREATE FUNCTION" bug fix  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: syntax error position "CREATE FUNCTION" bug fix
List pgsql-patches
Fabien COELHO <coelho@cri.ensmp.fr> writes:
>> 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.

But it cannot (easily) match it up with the *original input* and put the
cursor in the right place in the *input* window.  You are envisioning
something that's no better than psql with window borders.  My idea of a
GUI syntax error report is something that puts my editing cursor in the
right place.

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

It's not the right thing for other interfaces.  If it were the right
thing for all interfaces, we'd have put the functionality in the backend
to begin with.

            regards, tom lane

pgsql-patches by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: syntax error position "CREATE FUNCTION" bug fix
Next
From: Fabien COELHO
Date:
Subject: Re: syntax error position "CREATE FUNCTION" bug fix