diff options
author | Heikki Linnakangas <heikki.linnakangas@iki.fi> | 2012-08-06 13:02:15 +0300 |
---|---|---|
committer | Heikki Linnakangas <heikki.linnakangas@iki.fi> | 2012-08-06 14:14:44 +0300 |
commit | d9c77e249339ec3a49731be55ff22bbdd5a1fcf0 (patch) | |
tree | 891135f964782023a28db61d8fc6fa444f68eeeb /src/backend/utils/adt/json.c | |
parent | a411f7e770895b34035727bc44866e550cca892f (diff) | |
download | postgresql-d9c77e249339ec3a49731be55ff22bbdd5a1fcf0.tar.gz postgresql-d9c77e249339ec3a49731be55ff22bbdd5a1fcf0.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 'src/backend/utils/adt/json.c')
0 files changed, 0 insertions, 0 deletions