Re: Can PostgreSQL do data type automated casting
От | Mark Lewis |
---|---|
Тема | Re: Can PostgreSQL do data type automated casting |
Дата | |
Msg-id | 1132620482.5937.14.camel@archimedes обсуждение исходный текст |
Ответ на | Re: Can PostgreSQL do data type automated casting in prepared (Kris Jurka <books@ejurka.com>) |
Список | pgsql-jdbc |
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 >
В списке pgsql-jdbc по дате отправления: