Drat. I didn't realize that it's not possible to detect a bad statement
without invalidating the current transaction, that's definitely a no-
starter.
-- Mark
On Mon, 2005-11-21 at 19:28 -0500, Kris Jurka wrote:
>
> On Mon, 21 Nov 2005, Mark Lewis wrote:
>
> > Here's a thought; do you think it's feasible to detect cases where the
> > protocol=3 driver throws an error due to invalid or ambiguous typing
> > issues when the protocol=2 driver would just do the expected thing?
> >
> > Instead of throwing the error back to the user, could the driver then
> > issue a 'describe statement' call, use the result to disambiguate the
> > parameter settings, and re-issue the call? It increases the overhead
> > but only for the error cases, and the result could be cached to avoid
> > repeating that overhead.
> >
>
> There a number of problems with the fallback approach. First, since we've
> got a server error that will necessitate the transaction be rolled back so
> we'd have to establish a savepoint before every statement. Then you'd
> have to detect an error condition as being related to type resolution
> which isn't really clear. Even if this did work for people it certainly
> wouldn't be optimal because you could end up doing a lot more work,
> parsing twice and establishing and rolling back to savepoint, without
> knowing it. Your application would look like it was working, but it's
> certainly not how you want it to.
>
> Kris Jurka
>
