On Sat, 11 Feb 2006, Bruce Momjian wrote:
>
> Modified patch attached and applied. Thanks.
>
> I adjusted based on Tom's comments to use a zero byte, and to clean up
> the formatting. I didn't see any extra non-readline overhead, just
> calls to functions that are no-ops in non-readline cases.
Thank you, Bruce for modifying and applying the patch (during 2 months I
didn't find time to do that formatting corrections by myself).
> Tom Lane wrote:
> > "Sergey E. Koposov" <math@sai.msu.ru> writes:
> > > On Wed, 7 Dec 2005, Andrew Dunstan wrote:
> > >> A zero byte is probably a pretty bad choice. Some other low valued byte
> > >> (e.g. \x01 ) would probably work better.
> >
> > > Currently I replace '\n' with the '\x01' as Andrew suggested.
> >
> > Won't this get confused by some of the Far Eastern encodings we support?
> > The zero-byte approach is at least proof against that. But what we need
> > to ask is whether we can expect readline to cope with either.
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).
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) (for example I did a
test like this
cat ./pgsql/src/backend/utils/mb/Unicode/*.map |grep 01
cat ./pgsql/src/backend/utils/mb/Unicode/*.map |grep '0x1'
and it didn't produce any output, so it seems to me that 0x01 byte is not
used by any encoding... and UTF encodings are not using 0x01 byte for
certain)
The second alternative is to write our own implementations of read_history
and write_history functions instead of standart readline implementations to
deal with zero bytes in the strings. But it seems to be a rather bad
solution....
Regards,
Sergey
*****************************************************
Sergey E. Koposov
Max Planck Institute for Astronomy
Web: http://lnfm1.sai.msu.ru/~math
E-mail: math@sai.msu.ru
