Re: client side syntax error position (v3)

Fabien COELHO <coelho@cri.ensmp.fr> writes:
> New submission... after suggestions by Tom and others, the current result
> looks like the following:

> psql> CREATE foo;
> ERROR:  syntax error at or near "foo" at character 8
> LINE 1: CREATE foo;
>                ^
> psql>

I have applied this patch, after some considerable whacking around to
make it ready to cope with multicolumn Kanji characters.  It does not
actually cope yet, since the necessary knowledge is not available
from the character encoding logic.  But replacing the two places
that say

        scroffset += 1;        /* XXX fix me when we have screen width info */

with calls to a get-the-screen-width-of-this-character subroutine should
do the job.

I have temporarily fixed the problem shown in Fabien's original
regression tests:

  CREATE FUNCTION test1 (int) RETURNS int LANGUAGE sql
      AS 'not even SQL';
  ERROR:  syntax error at or near "not" at character 1
+ LINE 1: CREATE FUNCTION test1 (int) RETURNS int LANGUAGE sql
+         ^

by having the backend output a CONTEXT field in this case, and causing
psql to ignore the cursor position if there's a CONTEXT field.  This
is necessary AFAICS in the general case where a pre-existing function
gets an internal syntax error when called.  It'd be nice to do better in
the case of CREATE FUNCTION for a SQL function, but I don't currently
see how we can account for the string literal's starting position and
possible internal quotes, backslashes, etc etc.

            regards, tom lane