What is the state of play with this item? I think this is a must-fix bug
for 8.3. There was a flurry of messages back in April but since then I
don't recall seeing anything.
cheers
andrew
Mark Dilger wrote:
Mark Dilger wrote:
Bruce Momjian wrote:
Added to TODO:
* Fix cases where invalid byte encodings are accepted by the
database,
but throw an error on SELECT
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00767.php
Is anyone working on fixing this bug?
Hi, has anyone volunteered to fix this bug? I did not see any reply
on the mailing list to your question above.
mark
OK, I can take a stab at fixing this. I'd like to state some
assumptions so people can comment and reply:
I assume that I need to fix *all* cases where invalid byte encodings
get into the database through functions shipped in the core distribution.
I assume I do not need to worry about people getting bad data into the
system through their own database extensions.
I assume that the COPY problem discussed up-thread goes away once you
eliminate all the paths by which bad data can get into the system.
However, existing database installations with bad data already loaded
will not be magically fixed with these code patches.
Do any of the string functions (see
http://www.postgresql.org/docs/8.2/interactive/functions-string.html)
run the risk of generating invalid utf8 encoded strings? Do I need to
add checks? Are there known bugs with these functions in this regard?
If not, I assume I can add mbverify calls to the various input
routines (textin, varcharin, etc) where invalid utf8 could otherwise
enter the system.
I assume that this work can be limited to HEAD and that I don't need
to back-patch it. (I suspect this assumption is a contentious one.)
Advice and comments are welcome,
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings