BUG #4007: chr(0) doesn't work anymore

Started by Steve Clarkabout 18 years ago7 messagesbugs
Jump to latest
#1Steve Clark
sclark@netwolves.com

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.

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Steve Clark (#1)
Re: BUG #4007: chr(0) doesn't work anymore

"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

#3Steve Clark
sclark@netwolves.com
In reply to: Tom Lane (#2)
Re: BUG #4007: chr(0) doesn't work anymore

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

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Steve Clark (#3)
Re: BUG #4007: chr(0) doesn't work anymore

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

#5Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#4)
Re: [BUGS] BUG #4007: chr(0) doesn't work anymore

Tom Lane wrote:

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.

Seems we never documented that chr(0) is not supported. I have applied
the following doc patch to CVS HEAD and 8.3.X.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Attachments:

/rtmp/difftext/x-diffDownload+3-3
#6Andrew Dunstan
andrew@dunslane.net
In reply to: Bruce Momjian (#5)
Re: [BUGS] BUG #4007: chr(0) doesn't work anymore

Bruce Momjian wrote:

Tom Lane wrote:

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.

Seems we never documented that chr(0) is not supported. I have applied
the following doc patch to CVS HEAD and 8.3.X.

The NULL (0) character is not
allowed because text data types cannot reliably store such bytes.

"Reliably" is arguably misleading here.

cheers

andrew

#7Bruce Momjian
bruce@momjian.us
In reply to: Andrew Dunstan (#6)
Re: [BUGS] BUG #4007: chr(0) doesn't work anymore

BAndrew Dunstan wrote:

Bruce Momjian wrote:

Tom Lane wrote:

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.

Seems we never documented that chr(0) is not supported. I have applied
the following doc patch to CVS HEAD and 8.3.X.

The NULL (0) character is not
allowed because text data types cannot reliably store such bytes.

"Reliably" is arguably misleading here.

Agreed. "Reliably" word removed.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +