Sergey E. Koposov wrote:
> 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 
> 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.
> 

OK, seems you did your homework.  I will modify the code to use 0x01
unless someone can find an encoding we support that uses 0x01.  I will
use a macro for 0x01 so it is clearer.

> > 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).

Right, I tested that.  Even your patch, if someone does \e and edits a
query, and then exits psql and restarts it, the query is in lines,
right, so \e really doesn't work even without your patch.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to