Skip site navigation (1) Skip section navigation (2)

Re: JDBC driver's (non-)handling of InputStream:s

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: Peter Schuller <peter(dot)schuller(at)infidyne(dot)com>,PostgreSQL JDBC Mailing List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: JDBC driver's (non-)handling of InputStream:s
Date: 2004-03-30 22:39:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
Kris Jurka wrote:
> On Tue, 30 Mar 2004, Oliver Jowett wrote:
>>The "right way" to do it is to expand the driver's use of the V3 
>>protocol to use the extended query protocol; then the stream can be 
>>directly streamed to the backend without further 
>>translation/escaping/etc using a binary Bind parameter. But there's some 
>>infrastructure work to do before that can happen.
> Can we really stream an InputStream directly to the backend?  Don't we 
> need to prefix the message with a length argument?  and the only way to 
> get this with the InputStream API is to read the whole thing.  Yes, we can 
> avoid the translation/escaping, but I don't think we can avoid persisting 
> the InputStream at some point.

setBinaryStream() provides a length in addition to the stream. If the 
length is correct, we can calculate the query size ahead of time without 
reading the input stream. The spec is not entirely clear as to which is 
the length to insert; it implies it's an error to have a stream that 
doesn't match the provided length, but it's not explicit about what 
happens in that case.

If the length doesn't match the stream, we can deal with it: we can 
truncate to the specified length easily (emit a SQLWarning perhaps?), 
and an unexpected EOF can be treated like an IOException.


In response to

pgsql-jdbc by date

Next:From: Oliver JowettDate: 2004-03-30 22:53:24
Subject: Re: OutOfMemory
Previous:From: Kris JurkaDate: 2004-03-30 22:15:20
Subject: Re: JDBC driver's (non-)handling of InputStream:s

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group