Обсуждение: BUG #4007: chr(0) doesn't work anymore
The following bug has been logged online: Bug reference: 4007 Logged by: Steve Clark Email address: sclark@netwolves.com PostgreSQL version: 8.3.0 Operating system: FreeBSD 6.2 Description: chr(0) doesn't work anymore Details: Until 8.3.0 the following worked: SELECT coalesce(param_value,chr(0)) from t_system_params where param_name = 'default_unit_key'; it now fails with: ERROR: null character not permitted The documentation says: For other multibyte encodings the argument must designate a strictly ASCII character. NUL = 0 is a valid ascii character.
"Steve Clark" <sclark@netwolves.com> writes: > Until 8.3.0 the following worked: > SELECT coalesce(param_value,chr(0)) from t_system_params where param_name = > 'default_unit_key'; It would have "worked" only for rather small values of "work", since most of the support for type TEXT isn't null-safe. Try something like "select chr(0) || 'foo';" for example. Wouldn't an empty string do what you want better? > it now fails with: > ERROR: null character not permitted This is an intentional change and won't be undone, at least not until TEXT is null-safe, which isn't likely to happen in the foreseeable future. regards, tom lane
Tom Lane wrote: > "Steve Clark" <sclark@netwolves.com> writes: > >>Until 8.3.0 the following worked: >>SELECT coalesce(param_value,chr(0)) from t_system_params where param_name = >>'default_unit_key'; > > > It would have "worked" only for rather small values of "work", since > most of the support for type TEXT isn't null-safe. Try something like > "select chr(0) || 'foo';" for example. Wouldn't an empty string do what > you want better? > > >>it now fails with: >>ERROR: null character not permitted > > > This is an intentional change and won't be undone, at least not until > TEXT is null-safe, which isn't likely to happen in the foreseeable future. > > regards, tom lane > > Hi Tom, I'm not sure. This was written in 2001/2002 timeframe and I inherited it. I am not even sure what he was trying to accomplish. I'm not sure I understand what you mean about TEXT being null-safe. What are the issues, and why was it supported for years and now abruptly changed. All I know is the code used to work from 7.3.x up through 8.2.5 and now it doesn't. If it not going the made to work according to the documentation then the documentation should be fixed. Steve
Steve Clark <sclark@netwolves.com> writes: > I'm not sure I understand what you mean about TEXT being null-safe. > What are the issues, and why was > it supported for years and now abruptly changed. It never was supported, we are simply plugging a hole that let you create a text value that would be likely to malfunction in subsequent use. regards, tom lane