On Sat, 11 Feb 2006, Tom Lane wrote:
> "Sergey E. Koposov" <[EMAIL PROTECTED]> 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
2) UCS, UTF don't use 0x01 inside the multibyte chars.
3) I looked on the most problematic encodings like BIG5, JIS, SJIS,
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).
Sergey E. Koposov
Max Planck Institute for Astronomy
E-mail: [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?