This is the main PostgreSQL git repository. http://git.postgresql.org/cgit/postgresql.git/atom?h=master 2026-01-01T18:24:10Z 2026-01-01T18:24:10Z Bruce Momjian 2026-01-01T18:24:10Z urn:sha1:451c43974f8e199097d97624a4952ad0973cea61 Backpatch-through: 14 2025-01-01T16:21:55Z Bruce Momjian 2025-01-01T16:21:55Z urn:sha1:50e6eb731d98ab6d0e625a0b87fb327b172bbebd Backpatch-through: 13 2024-01-04T01:49:05Z Bruce Momjian 2024-01-04T01:49:05Z urn:sha1:29275b1d177096597675b5c6e7e7c9db2df8f4df Reported-by: Michael Paquier Discussion: https://postgr.es/m/ZZKTDPxBBMt3C0J9@paquier.xyz Backpatch-through: 12 2023-01-02T20:00:37Z Bruce Momjian 2023-01-02T20:00:37Z urn:sha1:c8e1ba736b2b9e8c98d37a5b77c4ed31baf94147 Backpatch-through: 11 2022-01-08T00:04:57Z Bruce Momjian 2022-01-08T00:04:57Z urn:sha1:27b77ecf9f4d5be211900eda54d8155ada50d696 Backpatch-through: 10 2021-01-02T18:06:25Z Bruce Momjian 2021-01-02T18:06:25Z urn:sha1:ca3b37487be333a1d241dab1bbdd17a211a88f43 Backpatch-through: 9.5 2020-06-12T16:14:32Z Tom Lane 2020-06-12T16:14:32Z urn:sha1:2f48ede080f42b97b594fb14102c82ca1001b80c plpgsql has always executed the query given in a RETURN QUERY command by opening it as a cursor and then fetching a few rows at a time, which it turns around and dumps into the function's result tuplestore. The point of this was to keep from blowing out memory with an oversized SPITupleTable result (note that while a tuplestore can spill tuples to disk, SPITupleTable cannot). However, it's rather inefficient, both because of extra data copying and because of executor entry/exit overhead. In recent versions, a new performance problem has emerged: use of a cursor prevents use of a parallel plan for the executed query. We can improve matters by skipping use of a cursor and having the executor push result tuples directly into the function's result tuplestore. However, a moderate amount of new infrastructure is needed to make that idea work: * We can use the existing tstoreReceiver.c DestReceiver code to funnel executor output to the tuplestore, but it has to be extended to support plpgsql's requirement for possibly applying a tuple conversion map. * SPI needs to be extended to allow use of a caller-supplied DestReceiver instead of its usual receiver that puts tuples into a SPITupleTable. Two new API calls are needed to handle both the RETURN QUERY and RETURN QUERY EXECUTE cases. I also felt that I didn't want these new API calls to use the legacy method of specifying query parameter values with "char" null flags (the old ' '/'n' convention); rather they should accept ParamListInfo objects containing the parameter type and value info. This required a bit of additional new infrastructure since we didn't yet have any parse analysis callback that would interpret $N parameter symbols according to type data supplied in a ParamListInfo. There seems to be no harm in letting makeParamList install that callback by default, rather than leaving a new ParamListInfo's parserSetup hook as NULL. (Indeed, as of HEAD, I couldn't find anyplace that was using the parserSetup field at all; plpgsql was using parserSetupArg for its own purposes, but parserSetup seemed to be write-only.) We can actually get plpgsql out of the business of using legacy null flags altogether, and using ParamListInfo instead of its ad-hoc PreparedParamsData structure; but this requires inventing one more SPI API call that can replace SPI_cursor_open_with_args. That seems worth doing, though. SPI_execute_with_args and SPI_cursor_open_with_args are now unused anywhere in the core PG distribution. Perhaps someday we could deprecate/remove them. But cleaning up the crufty bits of the SPI API is a task for a different patch. Per bug #16040 from Jeremy Smith. This is unfortunately too invasive to consider back-patching. Patch by me; thanks to Hamid Akhtar for review. Discussion: https://postgr.es/m/16040-eaacad11fecfb198@postgresql.org 2020-01-01T17:21:45Z Bruce Momjian 2020-01-01T17:21:45Z urn:sha1:7559d8ebfa11d98728e816f6b655582ce41150f3 Backpatch-through: update all files in master, backpatch legal files through 9.4 2019-05-22T17:04:48Z Tom Lane 2019-05-22T17:04:48Z urn:sha1:8255c7a5eeba8f1a38b7a431c04909bde4f5e67d Switch to 2.1 version of pg_bsd_indent. This formats multiline function declarations "correctly", that is with additional lines of parameter declarations indented to match where the first line's left parenthesis is. Discussion: https://postgr.es/m/CAEepm=0P3FeTXRcU5B2W3jv3PgRVZ-kGUXLGfd42FFhUROO3ug@mail.gmail.com 2019-01-02T17:44:25Z Bruce Momjian 2019-01-02T17:44:25Z urn:sha1:97c39498e5ca9208d3de5a443a2282923619bf91 Backpatch-through: certain files through 9.4