Re: TODO item -- Improve psql's handling of multi-line - Mailing list pgsql-patches

From Sergey E. Koposov
Subject Re: TODO item -- Improve psql's handling of multi-line
Date
Msg-id Pine.LNX.4.44.0602120642500.15708-100000@lnfm1.sai.msu.ru
Whole thread Raw
In response to Re: TODO item -- Improve psql's handling of multi-line  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: TODO item -- Improve psql's handling of multi-line  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
On Sat, 11 Feb 2006, Tom Lane wrote:

> "Sergey E. Koposov" <math@sai.msu.ru> writes:
> > But concerning to your zero byte change, it currently just broke
> > everything (as I thought, and that's why I didn't implemented it). The
> > problem with using zero byte is that it breaks all the readline functions
> > read_history and write_history. Those functions deal with usual C
> > strings, so putting zero byte inside them will just truncate everything.
> > (that's exactly what occur with the psql from CVS).
>
> If CVS tip is actually broken, we'd better revert this patch and
> rethink the approach.
>
> > So, I don't know. There are two alternatives. One is to use 0x01 byte
> > instead: (at least I don't really agree with Tom's comments about possible
> > problems with using 0x01 with some exotic encodings)
>
> Just because you don't use far eastern encodings doesn't mean there's
> not a large contingent who do.
>

I have said the phrase that I don't agree only after at least some
checking of the encodings:
1) First I greped the map files
pgsql/src/backend/utils/mb/Unicode/*.map and there is no 0x01 byte in any
encoding.
2) UCS, UTF don't use 0x01 inside the multibyte chars.
3) I looked on the most problematic encodings like BIG5, JIS, SJIS,
ISO-2022-JP
http://en.wikipedia.org/wiki/Big5
http://lfw.org/text/jp.html
and they certainly don't use the 0x01 byte.
So myself I'm rather convinced that the 0x01 byte is safe. Probably that's
not true, but I have no evidence for that.


> I don't understand why any of these shenanigans are needed.  If \e is
> able to stick a multiline entry into the history, why can't the other
> code do it?
>

The problem is in saving those multiline queries to the disk and
loading them again as multiline on next psql session and not with
putting the queries into the history for one psql session (that thing
works with that patch perfectly fine).


Regards,
    Sergey

*****************************************************
Sergey E. Koposov
Max Planck Institute for Astronomy
Web: http://lnfm1.sai.msu.ru/~math
E-mail: math@sai.msu.ru



pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Uninstall scripts for contrib
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] to_char and i18n