Re: Problems with protocol V3 after migration to latest driver
От | Alexey Yudichev |
---|---|
Тема | Re: Problems with protocol V3 after migration to latest driver |
Дата | |
Msg-id | 8BCBF9DB739F034B87FE7C7D30EAE55C026AC205@hqex2k.francoudi.com обсуждение исходный текст |
Ответ на | Problems with protocol V3 after migration to latest driver ("Alexey Yudichev" <Alexey@francoudi.com>) |
Ответы |
Re: Problems with protocol V3 after migration to latest driver
|
Список | pgsql-jdbc |
>Also, any thoughts on making the LO vs. bytea behaviour a separate >option, rather than lumping it in with 7.1 compatibility? It seems quite >possible that you might want to use LOs for get/setBytes() but use the >most up to date driver behaviour elsewhere. Are there any other changes in driver behaviour triggered by compatibility=7.1 other than LO-related ones? If yes, that wouldbe a good idea to separate them from LO changes, because LOs are the only reason I use compatibility=7.1 parameter. -----Original Message----- From: Oliver Jowett [mailto:oliver@opencloud.com] Sent: Monday, October 25, 2004 12:16 PM To: Kris Jurka Cc: pgsql-jdbc@postgresql.org Subject: Re: [JDBC] Problems with protocol V3 after migration to latest driver Kris Jurka wrote: > The first time through it does not fail because the driver > needs to query the backend to get some setup information for large objects > which starts a transaction. Sounds like that is (another) bug .. it should be using the QUERY_SUPPRESS_BEGIN flag for driver-generated queries to avoid starting a transaction accidentally. I fixed that in various other places but didn't think to check the LO code. Also, any thoughts on making the LO vs. bytea behaviour a separate option, rather than lumping it in with 7.1 compatibility? It seems quite possible that you might want to use LOs for get/setBytes() but use the most up to date driver behaviour elsewhere. -O ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
В списке pgsql-jdbc по дате отправления: