Tom Lane skrev:
Is this not a bug?
I don't actually see that it is. The documentation is perfectly clear
on the point:
(It is your responsibility that the byte sequences you create
are valid characters in the server character set encoding.)
(This is in 4.1.2.1. String
On Tue, 2006-10-31 at 23:18 -0500, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
Is this not a bug?
I don't actually see that it is. The documentation is perfectly clear
on the point:
(It is your responsibility that the byte sequences you create
are valid characters
On Fri, 2006-10-27 at 14:42 -0700, Jeff Davis wrote:
You can insert invalid UTF8 bytes sequences into a TEXT type on an 8.1
installation by doing something like:
I created a patch that appears to fix the problem, and does not appear
to break anything else.
Is this acceptable?
Regards,
Jeff Davis [EMAIL PROTECTED] writes:
I created a patch that appears to fix the problem, and does not appear
to break anything else.
... except maybe bytea ...
regards, tom lane
---(end of broadcast)---
TIP 9: In versions
On Tue, 2006-10-31 at 16:13 -0500, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
I created a patch that appears to fix the problem, and does not appear
to break anything else.
... except maybe bytea ...
Ok. So then it seems that the only possible places to fix it are in
textin
Jeff Davis [EMAIL PROTECTED] writes:
Is this not a bug?
I don't actually see that it is. The documentation is perfectly clear
on the point:
(It is your responsibility that the byte sequences you create
are valid characters in the server character set encoding.)
(This is in
On 27/10/06, Thomas H. [EMAIL PROTECTED] wrote:
FYI, prior to 8.2, there is another source of bad UTF8 byte sequences:
when using tsearch2 on utf8 content in 8.2, tsearch2 was generating bad
utf8 sequences. as tsearch2 does lowercase each char in the text its
indexing, it did also do so with
You can insert invalid UTF8 bytes sequences into a TEXT type on an 8.1
installation by doing something like:
INSERT INTO foo(t) VALUES('\xFF');
Then, you can do a:
COPY foo TO '/some/file';
but if you try to do a:
COPY foo FROM '/some/file';
That will fail because /some/file contains invalid
On Fri, 2006-10-27 at 14:42 -0700, Jeff Davis wrote:
It seems to be essentially a data corruption issue if applications
insert binary data in text fields using escape sequences. Shouldn't
PostgreSQL reject an invalid UTF8 sequence in any text type?
Another note: PostgreSQL rejects invalid
FYI, prior to 8.2, there is another source of bad UTF8 byte sequences:
when using tsearch2 on utf8 content in 8.2, tsearch2 was generating bad
utf8 sequences. as tsearch2 does lowercase each char in the text its
indexing, it did also do so with multibyte-characters... unfortunately
taking
10 matches
Mail list logo
