Re: insert char(1) type by different ways.
От | Karel Zak |
---|---|
Тема | Re: insert char(1) type by different ways. |
Дата | |
Msg-id | Pine.LNX.3.96.1010205095135.24877A-100000@ara.zf.jcu.cz обсуждение исходный текст |
Ответ на | Re: insert char(1) type by different ways. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: