aboutsummaryrefslogtreecommitdiff
path: root/src/pl/plpython/plpy_plpymodule.c
Commit message (Collapse)AuthorAge
* Final pgindent + perltidy run for 9.6.Tom Lane2016-08-15
|
* PL/Python: Report argument parsing errors using exceptionsPeter Eisentraut2016-07-02
| | | | | | | Instead of calling PLy_elog() for reporting Python argument parsing errors, generate appropriate exceptions. This matches the existing plpy functions and is more consistent with the behavior of the Python argument parsing routines.
* PL/Python: Rename new keyword arguments of plpy.error() etc.Peter Eisentraut2016-06-11
| | | | | Rename schema -> schema_name etc. to remain consistent with C API and PL/pgSQL.
* pgindent run for 9.6Robert Haas2016-06-09
|
* Fix missing "volatile" in PLy_output().Tom Lane2016-04-11
| | | | | | | | Commit 5c3c3cd0a3046339 plastered "volatile" on a bunch of variables in PLy_output(), but removed the one that actually mattered, ie the one on "oldcontext". This allows some versions of clang to generate code in which "oldcontext" has been trashed when control reaches the PG_CATCH block. Per buildfarm member tick.
* Fix poorly thought-through code from commit 5c3c3cd0a3046339.Tom Lane2016-04-11
| | | | | | | | | | | | | It's not entirely clear to me whether PyString_AsString can return null (looks like the answer might vary between Python 2 and 3). But in any case, this code's attempt to cope with the possibility was quite broken, because pstrdup() neither allows a null argument nor ever returns a null. Moreover, the code below this point assumes that "message" is a palloc'd string, which would not be the case for a dgettext result. Fix both problems by doing the pstrdup step separately.
* Enhanced custom error in PLPythonuTeodor Sigaev2016-04-08
| | | | | | | | Patch adds a new, more rich, way to emit error message or exception from PL/Pythonu code. Author: Pavel Stehule Reviewers: Catalin Iacob, Peter Eisentraut, Jim Nasby
* Fix some functions that were declared static then defined not-static.Tom Lane2015-01-12
| | | | Per testing with a compiler that whines about this.
* Improve hash_create's API for selecting simple-binary-key hash functions.Tom Lane2014-12-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, if you wanted anything besides C-string hash keys, you had to specify a custom hashing function to hash_create(). Nearly all such callers were specifying tag_hash or oid_hash; which is tedious, and rather error-prone, since a caller could easily miss the opportunity to optimize by using hash_uint32 when appropriate. Replace this with a design whereby callers using simple binary-data keys just specify HASH_BLOBS and don't need to mess with specific support functions. hash_create() itself will take care of optimizing when the key size is four bytes. This nets out saving a few hundred bytes of code space, and offers a measurable performance improvement in tidbitmap.c (which was not exploiting the opportunity to use hash_uint32 for its 4-byte keys). There might be some wins elsewhere too, I didn't analyze closely. In future we could look into offering a similar optimized hashing function for 8-byte keys. Under this design that could be done in a centralized and machine-independent fashion, whereas getting it right for keys of platform-dependent sizes would've been notationally painful before. For the moment, the old way still works fine, so as not to break source code compatibility for loadable modules. Eventually we might want to remove tag_hash and friends from the exported API altogether, since there's no real need for them to be explicitly referenced from outside dynahash.c. Teodor Sigaev and Tom Lane
* Run pgindent on 9.2 source tree in preparation for first 9.3Bruce Momjian2012-06-10
| | | | commit-fest.
* PL/Python: Improve error messagesPeter Eisentraut2012-04-25
|
* Patch some corner-case bugs in pl/python.Tom Lane2012-03-13
| | | | | | | | | | | | Dave Malcolm of Red Hat is working on a static code analysis tool for Python-related C code. It reported a number of problems in plpython, most of which were failures to check for NULL results from object-creation functions, so would only be an issue in very-low-memory situations. Patch in HEAD and 9.1. We could go further back but it's not clear that these issues are important enough to justify the work. Jan Urbański
* PL/Python: Add argument names to function declarationsPeter Eisentraut2011-12-29
| | | | For easier source reading
* Split plpython.c into smaller piecesPeter Eisentraut2011-12-18
This moves the code around from one huge file into hopefully logical and more manageable modules. For the most part, the code itself was not touched, except: PLy_function_handler and PLy_trigger_handler were renamed to PLy_exec_function and PLy_exec_trigger, because they were not actually handlers in the PL handler sense, and it makes the naming more similar to the way PL/pgSQL is organized. The initialization of the procedure caches was separated into a new function init_procedure_caches to keep the hash tables private to plpy_procedures.c. Jan Urbański and Peter Eisentraut