Heikki Linnakangas <heikki@enterprisedb.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