I have been looking at fixing the issue of accepting strings that are
not valid in the database encoding. It appears from previous discussion
that we need to add a call to pg_verifymbstr() to the relevant input
routines and ensure that the chr() function returns a valid string. That
leaves several issues:
. which are the relevant input routines? I have identified the following
as needing remediation: textin(), bpcharin(), varcharin(), anyenum_in(),
namein(). Do we also need one for cstring_in()? Does the xml code
handle this as part of xml validation?
. what do we need to do to make the verification code more efficient? I
think we need to address the correctness issue first, but doing so
should certainly make us want to improve the verification code. For
example, I'm wondering if it might benefit from having a tiny cache.
. for chr() under UTF8, it seems to be generally agreed that the
argument should represent the codepoint and the function should return
the correspondingly encoded character. If so, possible the argument
should be a bigint to accommodate the full range of possible code
points. It is not clear what the argument should represent for other
multi-byte encodings for any argument higher than 127. Similarly, it is
not clear what ascii() should return in such cases. I would be inclined
just to error out.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
