upstream/postgresql
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-02-27 20:00:50 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
postgresql/src/pl/plpython/expected/plpython_error.out

39 lines
2 KiB
Text
Raw Normal View History

Convert the existing regression test scripts for the various optional PLs to use the standard pg_regress infrastructure. No changes in the tests themselves. Andrew Dunstan
2005-05-14 13:55:22 -04:00
-- test error handling, i forgot to restore Warn_restart in
-- the trigger handler once. the errors and subsequent core dump were
-- interesting.
Add plpython code.
2001-05-09 15:54:38 -04:00
SELECT invalid_type_uncaught('rick');
Cleanup pass over PL/Python NLS. Add translation support to PLy_elog and PLy_exception_set, and clarify some error messages.
2009-01-15 08:49:57 -05:00
WARNING: PL/Python: in PL/Python function "invalid_type_uncaught"
plpython_error.out is for Python 2.4, plpython_error_3.out is for Python 2.5, as it was previously.
2009-01-16 15:21:46 -05:00
DETAIL: plpy.SPIError: unrecognized error in PLy_spi_prepare
Update to match error editing.
2003-07-25 20:02:02 -04:00
ERROR: type "test" does not exist
Add plpython code.
2001-05-09 15:54:38 -04:00
SELECT invalid_type_caught('rick');
Cleanup pass over PL/Python NLS. Add translation support to PLy_elog and PLy_exception_set, and clarify some error messages.
2009-01-15 08:49:57 -05:00
WARNING: PL/Python: in PL/Python function "invalid_type_caught"
plpython_error.out is for Python 2.4, plpython_error_3.out is for Python 2.5, as it was previously.
2009-01-16 15:21:46 -05:00
DETAIL: plpy.SPIError: unrecognized error in PLy_spi_prepare
Update to match error editing.
2003-07-25 20:02:02 -04:00
ERROR: type "test" does not exist
Add plpython code.
2001-05-09 15:54:38 -04:00
SELECT invalid_type_reraised('rick');
Cleanup pass over PL/Python NLS. Add translation support to PLy_elog and PLy_exception_set, and clarify some error messages.
2009-01-15 08:49:57 -05:00
WARNING: PL/Python: in PL/Python function "invalid_type_reraised"
plpython_error.out is for Python 2.4, plpython_error_3.out is for Python 2.5, as it was previously.
2009-01-16 15:21:46 -05:00
DETAIL: plpy.SPIError: unrecognized error in PLy_spi_prepare
Update to match error editing.
2003-07-25 20:02:02 -04:00
ERROR: type "test" does not exist
Add plpython code.
2001-05-09 15:54:38 -04:00
SELECT valid_type('rick');
valid_type
------------
(1 row)
This patch addresses the problem mentioned in the "process crash when a plpython function returns unicode" thread: http://archives.postgresql.org/pgsql-bugs/2005-06/msg00105.php In several places PL/Python was calling PyObject_Str() and then PyString_AsString() without checking if the former had returned NULL to indicate an error. PyString_AsString() doesn't expect a NULL argument, so passing one causes a segmentation fault. This patch adds checks for NULL and raises errors via PLy_elog(), which prints details of the underlying Python exception. The patch also adds regression tests for these checks. All tests pass on my Solaris 9 box running HEAD and Python 2.4.1. In one place the patch doesn't call PLy_elog() because that could cause infinite recursion; see the comment I added. I'm not sure how to test that particular case or whether it's even possible to get an error there: the value that the code should check is the Python exception type, so I wonder if a NULL value "shouldn't happen." This patch converts NULL to "Unknown Exception" but I wonder if an Assert() would be appropriate. The patch is against HEAD but the same changes should be applied to earlier versions because they have the same problem. The patch might not apply cleanly against earlier versions -- will the committer take care of little differences or should I submit different versions of the patch? Michael Fuhr
2005-07-10 00:56:55 -04:00
--
-- Test Unicode error handling.
--
SELECT unicode_return_error();
Cleanup pass over PL/Python NLS. Add translation support to PLy_elog and PLy_exception_set, and clarify some error messages.
2009-01-15 08:49:57 -05:00
ERROR: PL/Python: could not create string representation of Python object in PL/Python function "unicode_return_error" while creating return value
plpython_error.out is for Python 2.4, plpython_error_3.out is for Python 2.5, as it was previously.
2009-01-16 15:21:46 -05:00
DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\x80' in position 0: ordinal not in range(128)
This patch addresses the problem mentioned in the "process crash when a plpython function returns unicode" thread: http://archives.postgresql.org/pgsql-bugs/2005-06/msg00105.php In several places PL/Python was calling PyObject_Str() and then PyString_AsString() without checking if the former had returned NULL to indicate an error. PyString_AsString() doesn't expect a NULL argument, so passing one causes a segmentation fault. This patch adds checks for NULL and raises errors via PLy_elog(), which prints details of the underlying Python exception. The patch also adds regression tests for these checks. All tests pass on my Solaris 9 box running HEAD and Python 2.4.1. In one place the patch doesn't call PLy_elog() because that could cause infinite recursion; see the comment I added. I'm not sure how to test that particular case or whether it's even possible to get an error there: the value that the code should check is the Python exception type, so I wonder if a NULL value "shouldn't happen." This patch converts NULL to "Unknown Exception" but I wonder if an Assert() would be appropriate. The patch is against HEAD but the same changes should be applied to earlier versions because they have the same problem. The patch might not apply cleanly against earlier versions -- will the committer take care of little differences or should I submit different versions of the patch? Michael Fuhr
2005-07-10 00:56:55 -04:00
INSERT INTO unicode_test (testvalue) VALUES ('test');
Cleanup pass over PL/Python NLS. Add translation support to PLy_elog and PLy_exception_set, and clarify some error messages.
2009-01-15 08:49:57 -05:00
ERROR: PL/Python: could not compute string representation of Python object in PL/Python function "unicode_trigger_error" while modifying trigger row
plpython_error.out is for Python 2.4, plpython_error_3.out is for Python 2.5, as it was previously.
2009-01-16 15:21:46 -05:00
DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\x80' in position 0: ordinal not in range(128)
This patch addresses the problem mentioned in the "process crash when a plpython function returns unicode" thread: http://archives.postgresql.org/pgsql-bugs/2005-06/msg00105.php In several places PL/Python was calling PyObject_Str() and then PyString_AsString() without checking if the former had returned NULL to indicate an error. PyString_AsString() doesn't expect a NULL argument, so passing one causes a segmentation fault. This patch adds checks for NULL and raises errors via PLy_elog(), which prints details of the underlying Python exception. The patch also adds regression tests for these checks. All tests pass on my Solaris 9 box running HEAD and Python 2.4.1. In one place the patch doesn't call PLy_elog() because that could cause infinite recursion; see the comment I added. I'm not sure how to test that particular case or whether it's even possible to get an error there: the value that the code should check is the Python exception type, so I wonder if a NULL value "shouldn't happen." This patch converts NULL to "Unknown Exception" but I wonder if an Assert() would be appropriate. The patch is against HEAD but the same changes should be applied to earlier versions because they have the same problem. The patch might not apply cleanly against earlier versions -- will the committer take care of little differences or should I submit different versions of the patch? Michael Fuhr
2005-07-10 00:56:55 -04:00
SELECT unicode_plan_error1();
Cleanup pass over PL/Python NLS. Add translation support to PLy_elog and PLy_exception_set, and clarify some error messages.
2009-01-15 08:49:57 -05:00
WARNING: PL/Python: in PL/Python function "unicode_plan_error1"
plpython_error.out is for Python 2.4, plpython_error_3.out is for Python 2.5, as it was previously.
2009-01-16 15:21:46 -05:00
DETAIL: plpy.Error: unrecognized error in PLy_spi_execute_plan
Cleanup pass over PL/Python NLS. Add translation support to PLy_elog and PLy_exception_set, and clarify some error messages.
2009-01-15 08:49:57 -05:00
ERROR: PL/Python: PL/Python function "unicode_plan_error1" could not execute plan
plpython_error.out is for Python 2.4, plpython_error_3.out is for Python 2.5, as it was previously.
2009-01-16 15:21:46 -05:00
DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\x80' in position 0: ordinal not in range(128)
This patch addresses the problem mentioned in the "process crash when a plpython function returns unicode" thread: http://archives.postgresql.org/pgsql-bugs/2005-06/msg00105.php In several places PL/Python was calling PyObject_Str() and then PyString_AsString() without checking if the former had returned NULL to indicate an error. PyString_AsString() doesn't expect a NULL argument, so passing one causes a segmentation fault. This patch adds checks for NULL and raises errors via PLy_elog(), which prints details of the underlying Python exception. The patch also adds regression tests for these checks. All tests pass on my Solaris 9 box running HEAD and Python 2.4.1. In one place the patch doesn't call PLy_elog() because that could cause infinite recursion; see the comment I added. I'm not sure how to test that particular case or whether it's even possible to get an error there: the value that the code should check is the Python exception type, so I wonder if a NULL value "shouldn't happen." This patch converts NULL to "Unknown Exception" but I wonder if an Assert() would be appropriate. The patch is against HEAD but the same changes should be applied to earlier versions because they have the same problem. The patch might not apply cleanly against earlier versions -- will the committer take care of little differences or should I submit different versions of the patch? Michael Fuhr
2005-07-10 00:56:55 -04:00
SELECT unicode_plan_error2();
Cleanup pass over PL/Python NLS. Add translation support to PLy_elog and PLy_exception_set, and clarify some error messages.
2009-01-15 08:49:57 -05:00
ERROR: PL/Python: PL/Python function "unicode_plan_error2" could not execute plan
plpython_error.out is for Python 2.4, plpython_error_3.out is for Python 2.5, as it was previously.
2009-01-16 15:21:46 -05:00
DETAIL: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\x80' in position 0: ordinal not in range(128)
Reference in a new issue Copy permalink