Re: [HACKERS] JDBC and Binary protocol error, for some statements
| От | Maciek Sakrejda |
|---|---|
| Тема | Re: [HACKERS] JDBC and Binary protocol error, for some statements |
| Дата | |
| Msg-id | AANLkTim9yud09tPLYnbKcAtv=jZHUqVY-1+2BeOS+0d=@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] JDBC and Binary protocol error, for some statements (Radosław Smogura <rsmogura@softperience.eu>) |
| Ответы |
Re: [HACKERS] JDBC and Binary protocol error, for some statements
Re: [HACKERS] JDBC and Binary protocol error, for some statements |
| Список | pgsql-jdbc |
> So, to summarise, I shouldn't believe server DescribeRow (in context of format), in this situation, but only I should lookat this what I asked > for, isn't it? If I asked for columns in binary format, I need to do binary reading regarding what server has responded? Yes, because in this case "0" doesn't mean "the result will be in text", it means, "you issued the statement-variant of Describe, so I'm not sure what the result format will be yet." > If I asked for odd columns in text, even in binary do I need to choose proper format basing only on my request? I don't quite understand this question, but I think so. I don't think there's ever a situation where the server will ignore your result format requests. > But to the last part of cited protocol specification, when I've sent message with statement parameter's type int4, int8,varchar the format > field wasn't set to 0, but 1. I wasn't able to reproduce that with my standalone test case. When I changed the parameter oid to 23, I still got the same behavior. Can you alter my test case to reproduce the error? --- Maciek Sakrejda | System Architect | Truviso 1065 E. Hillsdale Blvd., Suite 215 Foster City, CA 94404 (650) 242-3500 Main www.truviso.com
В списке pgsql-jdbc по дате отправления: