1
0
mirror of https://github.com/postgres/postgres.git synced 2025-11-18 02:02:55 +03:00

Revert "Drop unnamed portal immediately after execution to completion"

This reverts commit 1fd981f053, based on concerns that the logging
improvements do not justify the protocol breakage of dropping an unnamed
portal once its execution has completed.

It seems unlikely that one would try to send an execute or describe
message after the portal has been used, but if they do such
post-completion messages would not be able to process as the previous
versions.  Let's revert this change for now so as we keep compatibility
and consider a different solution.

The tests added by 76bba03312 track the pre-1fd981f05369 behavior, and
are still valid.

Discussion: https://postgr.es/m/CA+TgmoYFJyJNQw3RT7veO3M2BWRE9Aw4hprC5rOcawHZti-f8g@mail.gmail.com
This commit is contained in:
Michael Paquier
2025-11-14 14:37:10 +09:00
parent 8fa6b9030d
commit 910690415b
3 changed files with 18 additions and 29 deletions

View File

@@ -1006,8 +1006,8 @@ SELCT 1/0;<!-- this typo is intentional -->
<para>
If successfully created, a named portal object lasts till the end of the
current transaction, unless explicitly destroyed. An unnamed portal is
destroyed at the end of the transaction, or as soon as the statement
specifying the unnamed portal as destination is processed to completion. (Note
destroyed at the end of the transaction, or as soon as the next Bind
statement specifying the unnamed portal as destination is issued. (Note
that a simple Query message also destroys the unnamed portal.) Named
portals must be explicitly closed before they can be redefined by another
Bind message, but this is not required for the unnamed portal.