On Sat, Jul 23, 2005 at 10:38:59PM -0400, Tom Lane wrote:
> Well, if it is just a Python version issue then all we need do is add
> a variant expected-output file to match. I was just expressing a
> desire to know that for sure before we wallpaper over the symptom...
I just built Python 2.3 and it does indeed format the error differently
than later versions (the format appears to have changed in 2.3.1):
% python2.3
Python 2.3 (#1, Jul 24 2005, 06:18:30)
[GCC 3.4.2] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> str(u'\x80')
Traceback (most recent call last):
File "<stdin>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character '\u80' in position 0: ordinal not in range(128)
% python2.4
Python 2.4.1 (#1, Apr 6 2005, 09:52:02)
[GCC 3.4.2] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> str(u'\x80')
Traceback (most recent call last):
File "<stdin>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\x80' in position 0: ordinal not in range(128)
One could check the version of Python that PL/Python is using with
the following function (assuming that Python isn't so broken that
it would use the core of one version but find modules from another):
CREATE FUNCTION pyversion() RETURNS text AS $$
import sys
return sys.version
$$ LANGUAGE plpythonu;
I've attached two new files that should go in the plpython directory:
resultmap
expected/plpython_error_py23.out
A problem with this patch is that it assumes a version of Python
based on the OS, which might clean up the current buildfarm but
that isn't really correct. Is there a better way to handle this?
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/