Revert part of the previous patch that avoided using PLy_elog().
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>
Thu, 5 Jul 2012 20:40:25 +0000 (23:40 +0300)
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>
Thu, 5 Jul 2012 20:44:55 +0000 (23:44 +0300)
That caused the plpython_unicode regression test to fail on SQL_ASCII
encoding, as evidenced by the buildfarm. The reason is that with the patch,
you don't get the detail in the error message that you got before. That
detail is actually very informative, so rather than just adjust the expected
output, let's revert that part of the patch for now to make the buildfarm
green again, and figure out some other way to avoid the recursion of
PLy_elog() that doesn't lose the detail.

src/pl/plpython/plpython.c

index 2b2ddeffac2111ead86f5d9a55452548130583fd..85829a0d3b496b843738c676304065694a350af9 100644 (file)
@@ -3745,16 +3745,7 @@ PLyUnicode_Bytes(PyObject *unicode)
 
        rv = PyUnicode_AsEncodedString(unicode, serverenc, "strict");
        if (rv == NULL)
-       {
-               /*
-                * Use a plain ereport instead of PLy_elog to avoid recursion, if
-                * the traceback formatting functions try to do unicode to bytes
-                * conversion again.
-                */
-               ereport(ERROR,
-                               (errcode(ERRCODE_INTERNAL_ERROR),
-                                errmsg("could not convert Python Unicode object to PostgreSQL server encoding")));
-       }
+               PLy_elog(ERROR, "could not convert Python Unicode object to PostgreSQL server encoding");
        return rv;
 }