Re: Problem with fixed length fields. - Mailing list pgsql-jdbc

From Oliver Jowett
Subject Re: Problem with fixed length fields.
Date
Msg-id 417ACB47.3090101@opencloud.com
Whole thread Raw
In response to Re: Problem with fixed length fields.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Problem with fixed length fields.
List pgsql-jdbc
Tom Lane wrote:
> Oliver Jowett <oliver@opencloud.com> writes:
>
>>Tom Lane wrote:
>>
>>>Can you refrain from assigning a type at all?
>
>
>>Pushing on blindly with a Bind without knowing the actual type of the
>>parameters you're sending seems possible but dangerous. It'd preclude
>>using binary-format parameters for unknown types, at a minimum.
>
>
> I had in mind doing this *only* for setString; you would essentially be
> assuming that the resolved type was text, varchar, or char, which have
> interchangeable binary formats.

But the driver has no guarantee that the backend will infer one of these
particular types, right?

> It would probably be a good idea to do a Describe Statement to verify
> that the parameter got resolved as one of those, but this need not add
> a round-trip, since you could issue it with the Parse message.

Currently the driver issues Parse, Bind, Describe(portal), Execute,
Sync. If I understand correctly, you're suggesting we do Parse,
Describe(statement), Bind, Describe(portal), Execute, Sync.

If the backend infers something other than a text-based type in Parse,
doesn't Bad Stuff happen? (e.g. inserting random data into your database..)

We could certainly notice the type mismatch when the results of the
statement Describe come back, but by then it is too late, the query has
already been executed.

-O

pgsql-jdbc by date:

Previous
From: Tom Lane
Date:
Subject: Re: Problem with fixed length fields.
Next
From: Tom Lane
Date:
Subject: Re: Problem with fixed length fields.