Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings.
От | Heikki Linnakangas |
---|---|
Тема | Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings. |
Дата | |
Msg-id | 4FF5FAFF.7020403@iki.fi обсуждение исходный текст |
Ответы |
Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python
encodings.
|
Список | pgsql-hackers |
On 05.07.2012 23:31, Tom Lane wrote: > Heikki Linnakangas<heikki.linnakangas@iki.fi> writes: >> Fix mapping of PostgreSQL encodings to Python encodings. > > The buildfarm doesn't like this --- did you check for side effects on > regression test results? Hmm, I ran the regressions tests, but not with C encoding. With the patch, you no longer get the errdetail you used to, when an encoding conversion fails: > *************** > *** 41,47 **** > > SELECT unicode_plan1(); > ERROR: spiexceptions.InternalError: could not convert Python Unicode object to PostgreSQL server encoding > - DETAIL: UnicodeEncodeError: 'ascii' codec can't encode character u'\x80' in position 0: ordinal not in range(128) > CONTEXT: Traceback (most recent call last): > PL/Python function "unicode_plan1", line 3, in <module> > rv = plpy.execute(plan, [u"\x80"], 1) > --- 39,44 ---- We could just update the expected output, there's two expected outputs for this test case and one of them is now wrong. But it'd actually be quite a shame to lose that extra information, that's quite valuable. Perhaps we should go back to using PLu_elog() here, and find some other way to avoid the recursion. - Heikki
В списке pgsql-hackers по дате отправления: