Re: Can PostgreSQL do data type automated casting in prepared

From: Kris Jurka <books(at)ejurka(dot)com>
To: Mark Lewis <mark(dot)lewis(at)mir3(dot)com>
Cc: Tjioe Ai Xin <xinxincute(at)gmail(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Can PostgreSQL do data type automated casting in prepared
Date: 2005-11-22 00:28:00
Message-ID: Pine.BSO.4.61.0511211926360.32@leary.csoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

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

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Mark Lewis 2005-11-22 00:48:02 Re: Can PostgreSQL do data type automated casting
Previous Message Mark Lewis 2005-11-21 23:48:00 Re: Deploying my application (nesting the jar)