Re: insert char(1) type by different ways. - Mailing list pgsql-bugs

From Karel Zak
Subject Re: insert char(1) type by different ways.
Date
Msg-id Pine.LNX.3.96.1010205095135.24877A-100000@ara.zf.jcu.cz
Whole thread Raw
In response to Re: insert char(1) type by different ways.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Sat, 3 Feb 2001, Tom Lane wrote:

> "And. Andruikhanov" <andy@euinf.dp.ua> writes:
> > insert into ku values(1, '\000');
>
> This cannot work as you expect, because what comes out of the parser is
> a string containing a single null character --- and that's fed to a
> datatype input routine that expects a null-terminated string.  So the
> char(n) input routine thinks you entered just '', which it blank-pads
> to one character.
>
> In general the Postgres I/O routines are not friendly to embedded nulls.
> The char/varchar/text types could not support embedded nulls even
> without the I/O problem, because they depend on C library routines like
> strcoll(), and those routines don't support strings with embedded nulls.

 And how store \000 to DB to standard tuples without exotic LO?

 By the way, for example MySQL client lib has nice (simple) function
that make correction from "arbitrary-data" to string that is correct
for all MySQL FE/BE routines (function convert problematic chars to \Oct
format). It's good feature, because user not must yourself check all
strings and know how chars is right for used DB.

 x1 = "Boys don't cry";

 mysql_escape_string(x2, x1, strlen(x1));

 ... and x2 is "Boys don\'t cry"

 (I not sure if quote is good example, but for others problematic chars
is good tool.)

        Karel

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Re: syslog logging setup broken?
Next
From: gateley@jriver.com
Date:
Subject: Re: psql & "unexpected EOF on client connection"