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/
plpython_error/.*-darwin=plpython_error_py23
-- test error handling, i forgot to restore Warn_restart in
-- the trigger handler once. the errors and subsequent core dump were
-- interesting.
SELECT invalid_type_uncaught('rick');
WARNING: plpython: in function invalid_type_uncaught:
DETAIL: plpy.SPIError: Unknown error in PLy_spi_prepare
ERROR: type "test" does not exist
SELECT invalid_type_caught('rick');
WARNING: plpython: in function invalid_type_caught:
DETAIL: plpy.SPIError: Unknown error in PLy_spi_prepare
ERROR: type "test" does not exist
SELECT invalid_type_reraised('rick');
WARNING: plpython: in function invalid_type_reraised:
DETAIL: plpy.SPIError: Unknown error in PLy_spi_prepare
ERROR: type "test" does not exist
SELECT valid_type('rick');
valid_type
------------
(1 row)
--
-- Test Unicode error handling.
--
SELECT unicode_return_error();
ERROR: plpython: function "unicode_return_error" could not create return value
DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character
'\u80' in position 0: ordinal not in range(128)
INSERT INTO unicode_test (testvalue) VALUES ('test');
ERROR: plpython: function "unicode_trigger_error" could not modify tuple
DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character
'\u80' in position 0: ordinal not in range(128)
SELECT unicode_plan_error1();
WARNING: plpython: in function unicode_plan_error1:
DETAIL: plpy.Error: Unknown error in PLy_spi_execute_plan
ERROR: plpython: function "unicode_plan_error1" could not execute plan
DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character
'\u80' in position 0: ordinal not in range(128)
SELECT unicode_plan_error2();
ERROR: plpython: function "unicode_plan_error2" could not execute plan
DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character
'\u80' in position 0: ordinal not in range(128)
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
