<div dir="ltr"><div><div dir="ltr">On Tue, Jul 9, 2024 at 1:42 PM Martin Desruisseaux <<a href="mailto:martin.desruisseaux@geomatys.com">martin.desruisseaux@geomatys.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div><br><blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>
            <p>Basically, the BLOB API seems clearly designed to allow
              the implementation to stream the data on demand if it
              wants to (which is good), but as a side effect it doesn't
              provide a way for the caller to guarantee avoidance of
              copying the entire array (if the implementation happens to
              not stream the data on demand).</p>
          </div>
        </div>
      </div>
    </blockquote>
    <p>Right. The wish to "unwrap" the <font face="monospace">ByteArrayInputStream</font>
      original array come from the empirical observation that many of
      the JDBC drivers that we are using do not stream.</p></div></blockquote><div><br></div><div>So would you accept a solution to this problem in the java.sql package instead? For example by adding two new methods:</div><div><br></div><div style="margin-left:40px"><span style="font-family:monospace">java.sql.Blob.asByteBuffer()</span></div><div style="margin-left:40px"><span style="font-family:monospace">java.sql.Clob.asCharBuffer()</span></div></div><br clear="all"></div><div>-Archie</div><div><br></div><div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div></div>