I didn't described log correctly, 1st attached response is normal execution;
flags QUERY_SUPPRESS_BEGIN | QUERY_ONESHOT, 2nd is compiled statement
QUERY_SUPPRESS_BEGIN only.
Text format is marked as 0, binary format is 1.
The 1st shown execution (flags=17) is good, it tells that result is sended in
binary format, as int4, but 2nd one (flags=16) (statement compiled) result is
bad because
Server described row as text
07:52:06.061 (54) <=BE RowDescription(1)
07:52:06.061 (54) Field(,INT4,4,T)
but recieved "tuple" was clearly in binary format, 0x00, 0x00, 0x00, 0x02.
(Look at length should be 1 or 2 if it's text format and value 2)
Speaking it simple, server said "you will recive text data", but sent it as
binary encoded int.
I've checked this againt 8.4 and 9.0.1.
Maciek Sakrejda <msakrejda@truviso.com> Wednesday 24 November 2010 18:02:27
> >Result is oid=23, format=(0) T, value = 0x00,0x00,0x00,0x02
>
> What do you mean regarding the format? Are you just inferring that
> from the data? If memory serves, the format of a particular column is
> not specified anywhere other than the RowDescription, and according to
> your JDBC log output above, the server is telling you the format is
> text (1) (which is your point--it doesn't match the resulting
> data--but I want to make sure we're clear on what's actually going
> on).
It's jdbc2.PreparedStatementTest, form JDBC driver unit tests. I've exposed
sources here http://www.rsmogura.net/pgsql/pgjdbc_exp_20101124.tar.gz
compiled driver and unit tests are in parent directory.
In above all not related to this bug tests has been commented, just run ant
test.
> Also, can you narrow this down to a simple, self-contained test case
> (with code)? Even if it's against a custom driver build, that would be
> easier to investigate.
> ---
> Maciek Sakrejda | System Architect | Truviso
>
> 1065 E. Hillsdale Blvd., Suite 215
> Foster City, CA 94404
> (650) 242-3500 Main
> www.truviso.com
Kind regards,
Radek
