Re: Can PostgreSQL do data type automated casting in prepared
От | Kris Jurka |
---|---|
Тема | Re: Can PostgreSQL do data type automated casting in prepared |
Дата | |
Msg-id | Pine.BSO.4.61.0511211926360.32@leary.csoft.net обсуждение исходный текст |
Ответ на | Can PostgreSQL do data type automated casting in prepared statement? (Tjioe Ai Xin <xinxincute@gmail.com>) |
Ответы |
Re: Can PostgreSQL do data type automated casting
|
Список | 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
В списке pgsql-jdbc по дате отправления: