From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | wiktor(dot)wodecki(at)Net-m(dot)de, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: chr() function leads to OOM / killed connection with 8.1, 8.2 |
Date: | 2007-07-19 20:26:30 |
Message-ID: | 29451.1184876790@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> I agree we should do the above changes for the sake of robustness, but
> isn't the real problem here that chr function can return invalid byte
> sequences? That was actually discussed a while back (starting at
> http://archives.postgresql.org/pgsql-hackers/2007-04/msg00010.php) but
> that was inconclusive.
My thought about that is that there will *always* be ways to get
invalidly encoded text into the database (via bugs if nothing else),
and so we had better write code that doesn't crash on it. Allowing
chr() to act the way it does at least makes it relatively easy to test
such cases.
> Is there any other known loopholes to get invalid data in the database?
The convert() function is a loophole by definition.
Someday we may be able to label individual strings with their encodings,
which would allow convert() to behave in a less unsafe way. I'd be a
bit inclined to define chr() as returning LATIN1, or some other popular
single-byte encoding, when that happens.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Vishal Gungah | 2007-07-20 06:00:39 | BUG #3474: Failed to create batch file |
Previous Message | Heikki Linnakangas | 2007-07-19 20:12:40 | Re: chr() function leads to OOM / killed connection with 8.1, 8.2 |