aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>2012-08-06 13:02:15 +0300
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>2012-08-06 14:33:27 +0300
commit31595993901484d24c9ba62428c7abec207dd55e (patch)
treee528688bf4c50f09e26347691ea4c5162bdcd5d9 /doc/src
parentc9c95202b036ea75dec68a4afc1802f35b77a966 (diff)
downloadpostgresql-31595993901484d24c9ba62428c7abec207dd55e.tar.gz
postgresql-31595993901484d24c9ba62428c7abec207dd55e.zip
Perform conversion from Python unicode to string/bytes object via UTF-8.
We used to convert the unicode object directly to a string in the server encoding by calling Python's PyUnicode_AsEncodedString function. In other words, we used Python's routines to do the encoding. However, that has a few problems. First of all, it required keeping a mapping table of Python encoding names and PostgreSQL encodings. But the real killer was that Python doesn't support EUC_TW and MULE_INTERNAL encodings at all. Instead, convert the Python unicode object to UTF-8, and use PostgreSQL's encoding conversion functions to convert from UTF-8 to server encoding. We were already doing the same in the other direction in PLyUnicode_FromString, so this is more consistent, too. Note: This makes SQL_ASCII to behave more leniently. We used to map SQL_ASCII to Python's 'ascii', which on Python means strict 7-bit ASCII only, so you got an error if the python string contained anything but pure ASCII. You no longer get an error; you get the UTF-8 representation of the string instead. Backpatch to 9.0, where these conversions were introduced. Jan UrbaƄski
Diffstat (limited to 'doc/src')
0 files changed, 0 insertions, 0 deletions