Re: Making TEXT NUL-transparent
От | Pavel Stehule |
---|---|
Тема | Re: Making TEXT NUL-transparent |
Дата | |
Msg-id | CAFj8pRDX2mUoqhQex2Mi3RA7gJhim3dvffYM79bgMChRxCyk3Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Making TEXT NUL-transparent (Florian Weimer <fweimer@bfk.de>) |
Ответы |
Re: Making TEXT NUL-transparent
|
Список | pgsql-hackers |
2011/11/24 Florian Weimer <fweimer@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 <fweimer@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 >
В списке pgsql-hackers по дате отправления: