> I have applied this patch,
Thanks!
> 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 also looked into it, and it is also a little bit more complex, as the
extract width must be though from the terminal perspective. Thus the
truncation part must take into account the terminal lengths. I think it
would require an additionnal array to store character to terminal column
mapping that would be used when truncating. I'll do that as soon as the
needed routines are there for terminal lengths, and submit a new patch.
> 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
> + ^
>
> [...]
>
> but I don't currently see how we can account for the string literal's
> starting position and possible internal quotes, backslashes, etc etc.
Yep. A solution would be to generate the extract from the backend, where
the information is really available, but this has been ruled out by
previous discussions...
--
Fabien Coelho - [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
