postgresql/src/pl/plpython
Tom Lane 4b93f57999 Make plpgsql use its DTYPE_REC code paths for composite-type variables.
Formerly, DTYPE_REC was used only for variables declared as "record";
variables of named composite types used DTYPE_ROW, which is faster for
some purposes but much less flexible.  In particular, the ROW code paths
are entirely incapable of dealing with DDL-caused changes to the number
or data types of the columns of a row variable, once a particular plpgsql
function has been parsed for the first time in a session.  And, since the
stored representation of a ROW isn't a tuple, there wasn't any easy way
to deal with variables of domain-over-composite types, since the domain
constraint checking code would expect the value to be checked to be a
tuple.  A lesser, but still real, annoyance is that ROW format cannot
represent a true NULL composite value, only a row of per-field NULL
values, which is not exactly the same thing.

Hence, switch to using DTYPE_REC for all composite-typed variables,
whether "record", named composite type, or domain over named composite
type.  DTYPE_ROW remains but is used only for its native purpose, to
represent a fixed-at-compile-time list of variables, for instance the
targets of an INTO clause.

To accomplish this without taking significant performance losses, introduce
infrastructure that allows storing composite-type variables as "expanded
objects", similar to the "expanded array" infrastructure introduced in
commit 1dc5ebc90.  A composite variable's value is thereby kept (most of
the time) in the form of separate Datums, so that field accesses and
updates are not much more expensive than they were in the ROW format.
This holds the line, more or less, on performance of variables of named
composite types in field-access-intensive microbenchmarks, and makes
variables declared "record" perform much better than before in similar
tests.  In addition, the logic involved with enforcing composite-domain
constraints against updates of individual fields is in the expanded
record infrastructure not plpgsql proper, so that it might be reusable
for other purposes.

In further support of this, introduce a typcache feature for assigning a
unique-within-process identifier to each distinct tuple descriptor of
interest; in particular, DDL alterations on composite types result in a new
identifier for that type.  This allows very cheap detection of the need to
refresh tupdesc-dependent data.  This improves on the "tupDescSeqNo" idea
I had in commit 687f096ea: that assigned identifying sequence numbers to
successive versions of individual composite types, but the numbers were not
unique across different types, nor was there support for assigning numbers
to registered record types.

In passing, allow plpgsql functions to accept as well as return type
"record".  There was no good reason for the old restriction, and it
was out of step with most of the other PLs.

Tom Lane, reviewed by Pavel Stehule

Discussion: https://postgr.es/m/8962.1514399547@sss.pgh.pa.us
2018-02-13 18:52:21 -05:00
..
expected PL/Python: Fix tests for older Python versions 2018-01-22 12:09:52 -05:00
po Translation updates 2017-08-07 13:55:34 -04:00
sql PL/Python: Fix tests for older Python versions 2018-01-22 12:09:52 -05:00
.gitignore PL/Python: Improve Python 3 regression test setup 2012-09-16 22:26:33 -04:00
generate-spiexceptions.pl Update copyright for 2018 2018-01-02 23:30:12 -05:00
Makefile Transaction control in PL procedures 2018-01-22 08:43:06 -05:00
nls.mk Translation updates 2017-08-07 13:55:34 -04:00
plpy_cursorobject.c Improve type conversion of SPI_processed in Python 2018-01-20 08:02:01 -05:00
plpy_cursorobject.h Make PL/Python handle domain-type conversions correctly. 2017-11-16 16:23:04 -05:00
plpy_elog.c Add compiler hints to PLy_elog() 2017-11-29 09:56:49 -05:00
plpy_elog.h Add compiler hints to PLy_elog() 2017-11-29 09:56:49 -05:00
plpy_exec.c Fix uninitialized-variable compiler warning induced by commit e4128ee76. 2017-12-03 11:25:17 -05:00
plpy_exec.h Phase 2 of pgindent updates. 2017-06-21 15:19:25 -04:00
plpy_main.c Transaction control in PL procedures 2018-01-22 08:43:06 -05:00
plpy_main.h Phase 2 of pgindent updates. 2017-06-21 15:19:25 -04:00
plpy_planobject.c PL/Python: Add cursor and execute methods to plan object 2017-03-27 11:37:22 -04:00
plpy_planobject.h Make PL/Python handle domain-type conversions correctly. 2017-11-16 16:23:04 -05:00
plpy_plpymodule.c Transaction control in PL procedures 2018-01-22 08:43:06 -05:00
plpy_plpymodule.h Phase 2 of pgindent updates. 2017-06-21 15:19:25 -04:00
plpy_procedure.c Rethink MemoryContext creation to improve performance. 2017-12-13 13:55:16 -05:00
plpy_procedure.h SQL procedures 2017-11-30 11:03:20 -05:00
plpy_resultobject.c Consistently catch errors from Python _New() functions 2017-11-18 13:39:53 -05:00
plpy_resultobject.h Phase 2 of pgindent updates. 2017-06-21 15:19:25 -04:00
plpy_spi.c Improve type conversion of SPI_processed in Python 2018-01-20 08:02:01 -05:00
plpy_spi.h Phase 2 of pgindent updates. 2017-06-21 15:19:25 -04:00
plpy_subxactobject.c Use Py_RETURN_NONE where suitable 2017-09-29 16:51:39 -04:00
plpy_subxactobject.h Phase 2 of pgindent updates. 2017-06-21 15:19:25 -04:00
plpy_typeio.c Make plpgsql use its DTYPE_REC code paths for composite-type variables. 2018-02-13 18:52:21 -05:00
plpy_typeio.h Make plpgsql use its DTYPE_REC code paths for composite-type variables. 2018-02-13 18:52:21 -05:00
plpy_util.c Phase 2 of pgindent updates. 2017-06-21 15:19:25 -04:00
plpy_util.h Phase 2 of pgindent updates. 2017-06-21 15:19:25 -04:00
plpython.h Update copyright for 2018 2018-01-02 23:30:12 -05:00
plpython2u--1.0.sql Put comments on the installable procedural languages. 2011-07-03 19:03:51 -04:00
plpython2u--unpackaged--1.0.sql Create extension infrastructure for the core procedural languages. 2011-03-04 21:51:14 -05:00
plpython2u.control Create extension infrastructure for the core procedural languages. 2011-03-04 21:51:14 -05:00
plpython3u--1.0.sql Put comments on the installable procedural languages. 2011-07-03 19:03:51 -04:00
plpython3u--unpackaged--1.0.sql Create extension infrastructure for the core procedural languages. 2011-03-04 21:51:14 -05:00
plpython3u.control Create extension infrastructure for the core procedural languages. 2011-03-04 21:51:14 -05:00
plpythonu--1.0.sql Put comments on the installable procedural languages. 2011-07-03 19:03:51 -04:00
plpythonu--unpackaged--1.0.sql Create extension infrastructure for the core procedural languages. 2011-03-04 21:51:14 -05:00
plpythonu.control Create extension infrastructure for the core procedural languages. 2011-03-04 21:51:14 -05:00
regress-python3-mangle.mk Fix hstore_plpython test when python3 is used. 2015-10-04 22:29:03 +02:00