This what I done is
1. Send bind
2. Put on stack the requested format types
3. On bind complete get requestedFormats from stack.
4. When execute is complete (or portal suspend) then, use requestedFormats
to change the field formats received from describe or previously cached.
I assume server
Haven't really gotten much further, but an interesting note: the named
/ unnamed prepared statement and portal stuff seems to be a red
herring. I can add a name to the portal, or move to an unnamed
prepared statement, and I still see the same thing. Which is
interesting, since that's not what
I checked against other parameter bindings and it looks like problem is
connected with oid=0.
In those cases:
1. Executing statement with parameter sent as varchar, int, long, with
text and binary format is ok.
2. Executing statement with oid=0 fail always; I've sent parameter in text
mode
Maciek Sakrejda msakre...@truviso.com writes:
Since triggering the set of FEBE messages that leads to this was tied
deep into the guts of JDBC, I opted for raw wire protocol. It looks
like the following sequence of messages from the client leads to this
result format mixup:
1. Parse, with
Interesting. I think you're right. Looking at the Wireshark traffic
again, the driver seems to issue a portal-variant Describe when using
unnamed prepared statements, but as soon as the named prepared
statements kick in (per prepare threshold), the Describe is a
statement-variant Describe with the
Okay, looking at the JDBC side of things, I think JDBC doesn't
actually need that information (since, it always used text results
before Radosław's patch--the previous binary support was for
parameters only, right?). From looking at QueryExecutorImpl
(specifically sendOneQuery), it's clear that it
Hi,
Thank you for your response.
I would only ask to be sure...
So, to summarise, I shouldn't believe server DescribeRow (in context of
format), in this situation, but only I should look at this what I asked
for, isn't it? If I asked for columns in binary format, I need to do binary
reading
So, to summarise, I shouldn't believe server DescribeRow (in context of
format), in this situation, but only I should look at 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
On Thu, 25 Nov 2010 11:28:02 -0800, Maciek Sakrejda
msakre...@truviso.com
wrote:
So, to summarise, I shouldn't believe server DescribeRow (in context of
format), in this situation, but only I should look at this what I asked
for, isn't it? If I asked for columns in binary format, I need to do
Maciek Sakrejda msakre...@truviso.com writes:
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
OTOH, it seems possible that the JDBC driver might behave differently
depending on whether parameter types were prespecified or not --- it
might issue Describe earlier in order to get the parameter types,
perhaps.
Ah. Bingo:
boolean describeStatement = describeOnly || (!oneShot
Hm... I moved Bind before Describe, I now have
// Construct a new portal if needed.
Portal portal = null;
if (usePortal)
{
String portalName = C_ + (nextUniqueID++);
portal = new Portal(query, portalName);
}
sendBind(query,
21:43:02.264 (26) FE= Describe(statement=S_1)
You're still doing the statement-flavor Describe. As Tom pointed out,
this won't tell you the result types because it doesn't know them.
Actually, technically if you issue a statement-flavor Describe *after*
a Bind, the server does have this
Maciek Sakrejda msakre...@truviso.com writes:
21:43:02.264 (26) FE= Describe(statement=S_1)
You're still doing the statement-flavor Describe. As Tom pointed out,
this won't tell you the result types because it doesn't know them.
Actually, technically if you issue a statement-flavor Describe
Thank you, but I think about this last night. Opening unnecessary portals
isn't good idea, similarly sending 2nd describe when statement was
prepared. Currently JDBC drivers doesn't make this. I think better will be
to store what format we had requested on stack, and then coerce those
formats when
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,
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
Text format is marked as 0, binary format is 1.
Sorry--I misread the docs. This is consistent and something does look fishy.
Thanks for the tarball. I can take a look tonight.
---
Maciek Sakrejda | System Architect | Truviso
1065 E. Hillsdale Blvd., Suite 215
Foster City, CA 94404
(650)
I've run your test and I can confirm the error. I've looked at the
protocol traffic with Wireshark, and the back-end is clearly lying
about the format of the results in this particular case: as you
stated, the row description says text, but the data is in binary.
I also wrote a simple Java
19 matches
Mail list logo
