| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
| Cc: | Simon Connah <simon(dot)n(dot)connah(at)protonmail(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Prepared statements versus stored procedures |
| Date: | 2023-11-19 19:40:12 |
| Message-ID: | CAKFQuwZXD91VWGASxwotrOi_ftdbrC+kV-jvORupfE_PdkCxCQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Sun, Nov 19, 2023 at 11:09 AM Francisco Olarte <folarte(at)peoplecall(dot)com>
wrote:
> IIRC it does it once per
> transaction, but it should be in the docs.
>
There is no external caching for executing a CALL; the runtime executes the
procedure afresh each time. If it were any different that would have to be
documented.
You do not
> turn a stored procedure into a statement, you turn CALLING the stored
> procedure into a prepared statement,
Which is not possible. CALL is not a valid target for PREPARE; the valid
ones are documented.
The fact that store procedures do not return result sets - and are
procedures - and prepared statements are not procedures and can return
result sets makes any kind of direct comparison pretty meaningless in
practice. They do different things and solve different problems. Know
what the problem you are trying to solve is and which of the two are
plausible options will make itself clear.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PGUser2020 | 2023-11-19 20:37:45 | How can I return a UTF8 string from a hex representation in a latin9 database? |
| Previous Message | Simon Connah | 2023-11-19 18:36:06 | Re: Prepared statements versus stored procedures |