Re: Add PortalDrop in exec_execute_message - Mailing list pgsql-hackers
From | Yura Sokolov |
---|---|
Subject | Re: Add PortalDrop in exec_execute_message |
Date | |
Msg-id | [email protected] Whole thread Raw |
In response to | Re: Add PortalDrop in exec_execute_message (Alvaro Herrera <[email protected]>) |
Responses |
Re: Add PortalDrop in exec_execute_message
|
List | pgsql-hackers |
Alvaro Herrera wrote 2021-06-08 00:07: > On 2021-May-27, Yura Sokolov wrote: > >> Alvaro Herrera писал 2021-05-26 23:59: > >> > I don't think they should do that. The portal remains open, and the >> > libpq interface does that. The portal gets closed at end of transaction >> > without the need for any client message. I think if the client wanted >> > to close the portal ahead of time, it would need a new libpq entry point >> > to send the message to do that. >> >> - PQsendQuery issues Query message, and exec_simple_query closes its >> portal. >> - people doesn't expect PQsendQueryParams to be different from >> PQsendQuery aside of parameter sending. The fact that the portal >> remains open is a significant, unexpected and undesired difference. >> - PQsendQueryGuts is used in PQsendQueryParams and >> PQsendQueryPrepared. >> It is always sends empty portal name and always "send me all rows" >> limit (zero). Both usages are certainly to just perform query and >> certainly no one expects portal remains open. > > Thinking about it some more, Yura's argument about PQsendQuery does > make > sense -- since what we're doing is replacing the use of a 'Q' message > just because we can't use it when in pipeline mode, then it is > reasonable to think that the replacement ought to have the same > behavior. Upon receipt of a 'Q' message, the portal is closed > automatically, and ISTM that that behavior should be preserved. > > That change would not solve the problem he complains about, because > IIUC > his framework is using PQsendQueryPrepared, which I'm not proposing to > change. It just removes the other discrepancy that was discussed in > the > thread. > > The attached patch does it. Any opinions? I'm propose to change PQsendQueryParams and PQsendQueryPrepared (through change of PQsendQueryGuts) since they both has semantic "execute unnamed portal till the end and send me all rows". Extended protocol were introduced by Tom Lane on 2003-05-05 in 16503e6fa4a13051debe09698b6db9ce0d509af8 This commit already has Close ('C') message. https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=16503e6fa4a13051debe09698b6db9ce0d509af8 libpq adoption of extended protocol were made by Tom month later on 2003-06-23 in efc3a25bb02ada63158fe7006673518b005261ba and there is already no Close message in PQsendQueryParams. https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=efc3a25bb02ada63158fe7006673518b005261ba I didn't found any relevant discussion in pgsql-hackers on May and June 2003. This makes me think, Close message were intended to be used but simply forgotten when libpq patch were made. Tom, could I be right? regards, Yura.
pgsql-hackers by date: