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