| From: | Neil Conway <neilc(at)samurai(dot)com> |
|---|---|
| To: | Dmitry Tkach <dmitry(at)openratings(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org, pgsql-jdbc(at)postgresql(dot)org |
| Subject: | Re: Prepared statement performance... |
| Date: | 2002-09-25 17:17:56 |
| Message-ID: | 87ptv2xa2j.fsf@mailbox.samurai.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-jdbc |
Dmitry Tkach <dmitry(at)openratings(dot)com> writes:
> - a general solution, that would involve extending postgres SQL gramma
> to include a 'prepare' statement
As someone else mentioned, this has been implemented for 7.3. I
implemented PREPARE/EXECUTE/DEALLOCATE on the backend side, Barry Lind
(I believe) added support for using backend prepared statements to the
JDBC driver.
> The second solution is not only ugly (because it requires the
> application code to be changed and to have a specialized stored
> procedure for every query), but also requires some additional hacks
> (to overcome the hard limit on the number of function arguments and
> the inability for functions to return tuples)
Note that in 7.3, functions can return sets of tuples.
Cheers,
Neil
--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Patrick Welche | 2002-09-25 19:22:24 | "lo" large object |
| Previous Message | Tom Lane | 2002-09-25 17:17:47 | Re: Administrator issue |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Felipe Schnack | 2002-09-25 18:59:56 | error codes |
| Previous Message | Shridhar Daithankar | 2002-09-25 15:33:28 | Re: Prepared statement performance... |