2011/11/24 Florian Weimer <fwei...@bfk.de>: > * Alexander Shulgin: > >>> It's actually UTF-8 text, and some PostgreSQL functions are only >>> available for TEXT, but not BYTEA, e.g.: >>> >>> bfk_int=> SELECT '\x006500'::bytea ~ 'A'; >>> ERROR: operator does not exist: bytea ~ unknown >> >> And how will those TEXT functions behave on a value with an embedded >> NUL? > > They need to be audited and fixed if necessary. I'm not saying that > this would be a trivial change. > >> Or is it not only about being able to *store* NULs in a text field? > > No, the entire core should be NUL-transparent. > > By the way, I refuse the notion that UTF-8 strings with embedded NULs > are "broken". I can't recall any other system which enforces UTF-8 > well-formedness, but does not permit embedded NULs. >
I have a different question. What is reason for embedded NULs inside strings? Regards Pavel Stehule > -- > Florian Weimer <fwei...@bfk.de> > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstraße 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers