diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2016-11-08 15:36:36 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2016-11-08 15:36:44 -0500 |
| commit | 9257f0787257022e31c61cd77449127adfccf37f (patch) | |
| tree | 4c75b862abe7b4d0610e280c97edc66390e283d0 /doc/src | |
| parent | dce429b117be027f059bb9df5c76eb5eadcc456d (diff) | |
Replace uses of SPI_modifytuple that intend to allocate in current context.
Invent a new function heap_modify_tuple_by_cols() that is functionally
equivalent to SPI_modifytuple except that it always allocates its result
by simple palloc. I chose however to make the API details a bit more
like heap_modify_tuple: pass a tupdesc rather than a Relation, and use
bool convention for the isnull array.
Use this function in place of SPI_modifytuple at all call sites where the
intended behavior is to allocate in current context. (There actually are
only two call sites left that depend on the old behavior, which makes me
wonder if we should just drop this function rather than keep it.)
This new function is easier to use than heap_modify_tuple() for purposes
of replacing a single column (or, really, any fixed number of columns).
There are a number of places where it would simplify the code to change
over, but I resisted that temptation for the moment ... everywhere except
in plpgsql's exec_assign_value(); changing that might offer some small
performance benefit, so I did it.
This is on the way to removing SPI_push/SPI_pop, but it seems like
good code cleanup in its own right.
Discussion: <9633.1478552022@sss.pgh.pa.us>
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/spi.sgml | 5 |
1 files changed, 3 insertions, 2 deletions
diff --git a/doc/src/sgml/spi.sgml b/doc/src/sgml/spi.sgml index 817a5d0120a..39133c90385 100644 --- a/doc/src/sgml/spi.sgml +++ b/doc/src/sgml/spi.sgml @@ -3382,8 +3382,9 @@ char * SPI_getnspname(Relation <parameter>rel</parameter>) <function>repalloc</function>, or SPI utility functions (except for <function>SPI_copytuple</function>, <function>SPI_returntuple</function>, - <function>SPI_modifytuple</function>, and - <function>SPI_palloc</function>) are made in this context. When a + <function>SPI_modifytuple</function>, + <function>SPI_palloc</function>, and + <function>SPI_datumTransfer</function>) are made in this context. When a procedure disconnects from the SPI manager (via <function>SPI_finish</function>) the current context is restored to the upper executor context, and all allocations made in the |