From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: CVS JDBC driver will try to use server-side-prepare on unpreparable SQL |
Date: | 2003-08-15 14:06:33 |
Message-ID: | 18109.1060956393@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Oliver Jowett <oliver(at)opencloud(dot)com> writes:
> It looks like the driver is trying to use server-side prepare on SQL that it
> won't work on:
Note that if you use the new-protocol Parse message, you can prepare
any SQL command.
I was thinking yesterday that it would not take very much more work
to make the PREPARE SQL command accept any SQL command after it, too.
But that's close enough to a new feature that I wasn't gonna do it
for 7.4. If you feel it's important for the JDBC driver then we can
talk about it. (Neither of these things would help you on a pre-7.4
server, of course, so maybe you need a different approach anyhow.)
> Should we only be doing PREPARE on queries that are known to be safe (e.g.
> single-statement SELECTs), or is it better to try to catch the errors and
> abandon the prepare? (more general, but sounds a bit hairy).
Uh, don't you have to be prepared to catch errors in PREPARE anyway?
What if the command is syntactically or semantically wrong?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | kevin | 2003-08-15 14:12:09 | resultset.first() untrappable error |
Previous Message | Oliver Jowett | 2003-08-15 12:17:45 | CVS JDBC driver will try to use server-side-prepare on unpreparable SQL |