aboutsummaryrefslogtreecommitdiff
path: root/src/pl/plpython/plpython.c
Commit message (Collapse)AuthorAge
* Pgindent run before 9.1 beta2.Bruce Momjian2011-06-09
|
* Message style improvementsPeter Eisentraut2011-05-21
|
* Use a macro variable PG_PRINTF_ATTRIBUTE for the style used for checking ↵Andrew Dunstan2011-04-28
| | | | | | | | | printf type functions. The style is set to "printf" for backwards compatibility everywhere except on Windows, where it is set to "gnu_printf", which eliminates hundreds of false error messages from modern versions of gcc arising from %m and %ll{d,u} formats.
* Fix PL/Python traceback for error in separate filePeter Eisentraut2011-04-20
| | | | | | | | | | | | It assumed that the lineno from the traceback always refers to the PL/Python function. If you created a PL/Python function that imports some code, runs it, and that code raises an exception, PLy_traceback would get utterly confused. Now we look at the file name reported with the traceback and only print the source line if it came from the PL/Python function. Jan Urbański
* pgindent run before PG 9.1 beta 1.Bruce Momjian2011-04-10
|
* Fix some sloppiness in new PL/python get_source_line() function.Robert Haas2011-04-08
| | | | Jan Urbański
* Add traceback information to PL/Python errorsPeter Eisentraut2011-04-06
| | | | | | | This mimics the traceback information the Python interpreter prints with exceptions. Jan Urbański
* Don't leak the temporary PLyProcedure struct we create for inline plpythonHeikki Linnakangas2011-03-31
| | | | | | blocks. Investigation by Jan Urbański, though I didn't use his patch.
* Fix PL/Python memory leak involving array slicesAlvaro Herrera2011-03-17
| | | | | Report and patch from Daniel Popowich, bug #5842 (with some debugging help from Alex Hunsaker)
* Fix behavior when raising plpy.Fatal()Peter Eisentraut2011-03-07
| | | | | | | It should cause a elog(FATAL) error, and it fact it was simply causing a elog(ERROR). Jan Urbański
* Report Python errors from iterators with PLy_elogPeter Eisentraut2011-03-07
| | | | | | | | | | This improves reporting, as the error string now includes the actual Python exception. As a side effect, this no longer sets the errcode to ERRCODE_DATA_EXCEPTION, which might be considered a feature, as it's not documented and not clear why iterator errors should be treated differently. Jan Urbański
* Suppress some "variable might be clobbered by longjmp" warnings.Tom Lane2011-03-06
| | | | | | Seen with an older gcc version. I'm not sure these represent any real risk factor, but still a bit scary. Anyway we have lots of other volatile-marked variables in this code, so a couple more won't hurt.
* Create extension infrastructure for the core procedural languages.Tom Lane2011-03-04
| | | | | | | | | | | | | | | | | | | | This mostly just involves creating control, install, and update-from-unpackaged scripts for them. However, I had to adjust plperl and plpython to not share the same support functions between variants, because we can't put the same function into multiple extensions. catversion bump forced due to new contents of pg_pltemplate, and because initdb now installs plpgsql as an extension not a bare language. Add support for regression testing these as extensions not bare languages. Fix a couple of other issues that popped up while testing this: my initial hack at pg_dump binary-upgrade support didn't work right, and we don't want an extra schema permissions test after all. Documentation changes still to come, but I'm committing now to see whether the MSVC build scripts need work (likely they do).
* Add a comment explaining the recent fix for plpython breakage in commit 4c966d9.Andrew Dunstan2011-03-03
| | | | Mostly text supplied by Jan Urbański.
* Fix plpython breakage detected on certain Fedora machines on buildfarm.Andrew Dunstan2011-03-01
| | | | Patch from Jan Urbański.
* PL/Python custom SPI exceptionsPeter Eisentraut2011-02-28
| | | | | | | | This provides a separate exception class for each error code that the backend defines, as well as the ability to get the SQLSTATE from the exception object. Jan Urbański, reviewed by Steve Singer
* PL/Python explicit subtransactionsPeter Eisentraut2011-02-27
| | | | | | | Adds a context manager, obtainable by plpy.subtransaction(), to run a group of statements in a subtransaction. Jan Urbański, reviewed by Steve Singer, additional scribbling by me
* Table function support for PL/PythonPeter Eisentraut2011-02-26
| | | | | | | This allows functions with multiple OUT parameters returning both one or multiple records (RECORD or SETOF RECORD). Jan Urbański, reviewed by Hitoshi Harada
* Add PL/Python functions for quoting stringsPeter Eisentraut2011-02-22
| | | | | | | | | | | | Add functions plpy.quote_ident, plpy.quote_literal, plpy.quote_nullable, which wrap the equivalent SQL functions. To be able to propagate char * constness properly, make the argument of quote_literal_cstr() const char *. This also makes it more consistent with quote_identifier(). Jan Urbański, reviewed by Hitoshi Harada, some refinements by Peter Eisentraut
* Invalidate PL/Python functions with composite type argument when thePeter Eisentraut2011-02-19
| | | | | | | | | type changes. The invalidation will cause the type information to be refetched, and everything will work. Jan Urbański, reviewed by Alex Hunsaker
* Fix for warnings-free compilation with Python 3.2Peter Eisentraut2011-02-16
| | | | | The first argument of PyEval_EvalCode() was changed from PyCodeObject* to PyObject* because of PEP 384.
* Wrap PL/Python SPI calls into subtransactionsPeter Eisentraut2011-02-02
| | | | | | | | | | | This allows the language-specific try/catch construct to catch and handle exceptions arising from SPI calls, matching the behavior of other PLs. As an additional bonus you no longer get all the ugly "unrecognized error in PLy_spi_execute_query" errors. Jan Urbański, reviewed by Steve Singer
* Add validator to PL/PythonPeter Eisentraut2011-02-01
| | | | Jan Urbański, reviewed by Hitoshi Harada
* Do not prefix error messages with the string "PL/Python: "Peter Eisentraut2011-01-27
| | | | | | It is redundant, given the error context. Jan Urbański
* Improve exception usage in PL/PythonPeter Eisentraut2011-01-27
| | | | | | | | | | Use the built-in TypeError, not SPIError, for errors having to do with argument counts or types. Use SPIError, not simply plpy.Error, for errors in PLy_spi_execute_plan. Finally, do not set a Python exception if PyArg_ParseTuple failed, as it already sets the correct exception. Jan Urbański
* Also save the error detail in SPIErrorPeter Eisentraut2011-01-27
| | | | | | | The temporarily broken plpython_unicode test shows a case where this is used. Do remaining fix-ups on the expected files at the same time.
* Fix compiler warningsPeter Eisentraut2011-01-27
| | | | | Older versions of GCC appear to report these with the current standard option set, newer versions need -Wformat-security.
* Call PLy_spi_execute_fetch_result inside the try/catch blockPeter Eisentraut2011-01-25
| | | | | | | This way errors from fetching tuples are correctly reported as errors in the SPI call. While at it, avoid palloc(0). Jan Urbański
* Refactor PLy_spi_prepare to save two levels of indentationPeter Eisentraut2011-01-24
| | | | | | | Instead of checking whether the arglist is NULL and then if its length is 0, do it in one step, and outside of the try/catch block. Jan Urbański
* Revert "Factor out functions responsible for caching I/O routines".Tom Lane2011-01-23
| | | | | | | | This reverts commit 740e54ca84c437fd67524f97a3ea9ddea752e208, which seems to have tickled an optimization bug in gcc 4.5.x, as reported upstream at https://bugzilla.redhat.com/show_bug.cgi?id=671899 Since this patch had no purpose beyond code beautification, it's not worth expending a lot of effort to look for another workaround.
* Get rid of the global variable holding the error statePeter Eisentraut2011-01-22
| | | | | | | | | | | | | | Global error handling led to confusion and was hard to manage. With this change, errors from PostgreSQL are immediately reported to Python as exceptions. This requires setting a Python exception after reporting the caught PostgreSQL error as a warning, because PLy_elog destroys the Python exception state. Ideally, all places where PostgreSQL errors need to be reported back to Python should be wrapped in subtransactions, to make going back to Python from a longjmp safe. This will be handled in a separate patch. Jan Urbański
* Correctly add exceptions to the plpy module for Python 3Peter Eisentraut2011-01-21
| | | | | | | | | | The way the exception types where added to the module was wrong for Python 3. Exception classes were not actually available from plpy. Fix that by factoring out code that is responsible for defining new Python exceptions and make it work with Python 3. New regression test makes sure the plpy module has the expected contents. Jan Urbanśki, slightly revised by me
* Fix wrong commentPeter Eisentraut2011-01-20
| | | | Hitoshi Harada
* Fix typoPeter Eisentraut2011-01-20
| | | | Hitoshi Harada
* Factor out functions responsible for caching I/O routinesPeter Eisentraut2011-01-20
| | | | | | This makes PLy_procedure_create a bit more manageable. Jan Urbański
* Add braces around an if block, for readabilityPeter Eisentraut2011-01-19
| | | | Jan Urbański, reviewed by Peter Eisentraut, Álvaro Herrera, Tom Lane :-)
* Free plan values in the PLyPlanObject dealloc functionPeter Eisentraut2011-01-19
| | | | Jan Urbański
* Improve message for errors in compiling anonymous PL/Python blocksPeter Eisentraut2011-01-19
| | | | | | The previous code would try to print out a null pointer. Jan Urbański
* Use PyObject_New instead of PyObject_NEWPeter Eisentraut2011-01-18
| | | | | | The latter is undocumented and the speed gain is negligible. Jan Urbański
* Skip dropped attributes when converting Python objects to tuplesPeter Eisentraut2011-01-18
| | | | | | | | Pay attention to the attisdropped field and skip over TupleDesc fields that have it set. Not a real problem until we get table returning functions, but it's the right thing to do anyway. Jan Urbański
* Use palloc in TopMemoryContext instead of mallocPeter Eisentraut2011-01-18
| | | | | | | As discussed, even if the PL needs a permanent memory location, it should use palloc, not malloc. It also makes error handling easier. Jan Urbański
* Fix an error when a set-returning function fails halfway through the executionPeter Eisentraut2011-01-18
| | | | | | | | | If the function using yield to return rows fails halfway, the iterator stays open and subsequent calls to the function will resume reading from it. The fix is to unref the iterator and set it to NULL if there has been an error. Jan Urbański
* Use HTABs instead of Python dictionary objects to cache proceduresPeter Eisentraut2011-01-17
| | | | | | | | | | | | | | | | | Two separate hash tables are used for regular procedures and for trigger procedures, since the way trigger procedures work is quite different from normal stored procedures. Change the signatures of PLy_procedure_{get,create} to accept the function OID and a Boolean flag indicating whether it's a trigger. This should make implementing a PL/Python validator easier. Using HTABs instead of Python dictionaries makes error recovery easier, and allows for procedures to be cached based on their OIDs, not their names. It also allows getting rid of the PyCObject field that used to hold a pointer to PLyProcedure, since PyCObjects are deprecated in Python 2.7 and replaced by Capsules in Python 3. Jan Urbański
* Increment Py_None refcount for NULL array elementsAlvaro Herrera2011-01-17
| | | | | Per bug #5835 by Julien Demoor Author: Alex Hunsaker
* Fix aboriginal mistake in plpython's set-returning-function support.Tom Lane2010-11-15
| | | | | | | | | | We must stay in the function's SPI context until done calling the iterator that returns the set result. Otherwise, any attempt to invoke SPI features in the python code called by the iterator will malfunction. Diagnosis and patch by Jan Urbanski, per bug report from Jean-Baptiste Quenot. Back-patch to 8.2; there was no support for SRFs in previous versions of plpython.
* Fix plpython so that it again honors typmod while assigning to tuple fields.Tom Lane2010-10-11
| | | | | This was broken in 9.0 while improving plpython's conversion behavior for bytea and boolean. Per bug report from maizi.
* Support triggers on views.Tom Lane2010-10-10
| | | | | | | | | | | | | | | This patch adds the SQL-standard concept of an INSTEAD OF trigger, which is fired instead of performing a physical insert/update/delete. The trigger function is passed the entire old and/or new rows of the view, and must figure out what to do to the underlying tables to implement the update. So this feature can be used to implement updatable views using trigger programming style rather than rule hacking. In passing, this patch corrects the names of some columns in the information_schema.triggers view. It seems the SQL committee renamed them somewhere between SQL:99 and SQL:2003. Dean Rasheed, reviewed by Bernd Helmle; some additional hacking by me.
* Fix sloppy usage of TRIGGER_FIRED_BEFORE/TRIGGER_FIRED_AFTER.Tom Lane2010-10-08
| | | | | | | | | | | | | | | | | | Various places were testing TRIGGER_FIRED_BEFORE() where what they really meant was !TRIGGER_FIRED_AFTER(), or vice versa. This needs to be cleaned up because there are about to be more than two possible states. We might want to note this in the 9.1 release notes as something for trigger authors to double-check. For consistency's sake I also changed some places that assumed that TRIGGER_FIRED_FOR_ROW and TRIGGER_FIRED_FOR_STATEMENT are necessarily mutually exclusive; that's not in immediate danger of breaking, but it's still sloppier than it should be. Extracted from Dean Rasheed's patch for triggers on views. I'm committing this separately since it's an identifiable separate issue, and is the only reason for the patch to touch most of these particular files.
* Remove cvs keywords from all files.Magnus Hagander2010-09-20
|
* Catch null pointer returns from PyCObject_AsVoidPtr and PyCObject_FromVoidPtrPeter Eisentraut2010-08-25
| | | | | | | | This is reproducibly possible in Python 2.7 if the user turned PendingDeprecationWarning into an error, but it's theoretically also possible in earlier versions in case of exceptional conditions. backpatched to 8.0
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-07 06:38:24 +0000