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: | Raw Message | Whole Thread | 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... |