pgsrv: Respect max rows paramter when executing a statement

[justinrubek]

A prepared statement that is used with Bind creates a portal which can be executed. The current implementation will execute the plan but does not respect the max rows parameter and also never sends a PortalSuspended message

postgres docs

Once a portal exists, it can be executed using an Execute message. The Execute message specifies the portal name (empty string denotes the unnamed portal) and a maximum result-row count (zero meaning “fetch all rows”). The result-row count is only meaningful for portals containing commands that return row sets; in other cases the command is always executed to completion, and the row count is ignored. The possible responses to Execute are the same as those described above for queries issued via simple query protocol, except that Execute doesn't cause ReadyForQuery or RowDescription to be issued.

If Execute terminates before completing the execution of a portal (due to reaching a nonzero result-row count), it will send a PortalSuspended message; the appearance of this message tells the frontend that another Execute should be issued against the same portal to complete the operation. The CommandComplete message indicating completion of the source SQL command is not sent until the portal's execution is completed. Therefore, an Execute phase is always terminated by the appearance of exactly one of these messages: CommandComplete, EmptyQueryResponse (if the portal was created from an empty query string), ErrorResponse, or PortalSuspended.

[greyscaled]

See: #131 (comment)

[scsmithr]

We support executing a statement, just not the max rows part. Updated title to reflect that.

[greyscaled]

Stale - can reopen later