Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tokio-postgres: add execute_prepared function #991

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mahkoh
Copy link

@mahkoh mahkoh commented Feb 9, 2023

As it says in the documentation:

This function is identical to execute_raw except that:

  1. The returned future does not borrow the parameters or self.
  2. The type of the returned future does not depend on the parameters.
  3. If multiple such futures are being used concurrently, then they are
    executed on the server in the order in which this function was
    called, regardless of the order in which the futures are polled.
  4. This function can only be used with prepared statements.

This has the following additional advantages:

  1. Multiple non-homogeneous execute futures can be stored in a collection without having to box the futures.
  2. The parameters can be temporaries that do not need to out-live the futures.
  3. We can rely on the order in which the futures reach the server without having to rely on polling order which might not always be documented.
  4. It is not necessary to poll the returned futures at all. An application can also only poll the final transaction commit.

As it says in the documentation:

> This function is identical to `execute_raw` except that:
>
> 1. The returned future does not borrow the parameters or `self`.
> 2. The type of the returned future does not depend on the parameters.
> 3. If multiple such futures are being used concurrently, then they are
>    executed on the server in the order in which this function was
>    called, regardless of the order in which the futures are polled.
> 4. This function can only be used with prepared statements.

This has the following additional advantages:

1. Multiple non-homogeneous `execute` futures can be stored in a
   collection without having to box the futures.
2. The parameters can be temporaries that do not need to out-live the
   futures.
3. We can rely on the order in which the futures reach the server
   without having to rely on polling order which might not always be
   documented.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant