Thomas Kellerer wrote:
> Hmm. At least for updating LOBs, "my method" should be "legal".
> This is a quote from jdbc-3_0-fr-spec.pdf
>
> "The setBinaryStream and setObject methods may also be used to set a
Blob
> object as a parameter in a PreparedStatement object. The
setAsciiStream,
> setCharact
Finally, I'd like to bring up my first question again.
Is there any plan to support BLOB and CLOB in future releases?
Don't you guys need a standard LOB feature? I no longer need it, though ;-p
With the current large objects feature, I don't think it's not difficult to
support it...
Thanks,
eb
EBIHARA, Yuichiro wrote on 22.06.2007 09:28:
Hmm. At least for updating LOBs, "my method" should be
"legal". This is a quote from jdbc-3_0-fr-spec.pdf
"The setBinaryStream and setObject methods may also be used
to set a Blob object as a parameter in a PreparedStatement
object. The setAsciiStr
Thomas,
> > According to JDBC 3.0 specifiction, those 4 methods may not be
> > compatible to BLOB/CLOB. Some databases may support them to
> access LOB
> > data but not all databases.
> >
> Hmm. At least for updating LOBs, "my method" should be
> "legal". This is a quote from jdbc-3_0-fr-spec
EBIHARA, Yuichiro wrote on 22.06.2007 08:34:
Thomas,
Thank you for your comment.
I found that using getBinaryStream(), setBinaryStream(),
getCharacterStream()
and setCharacterStream() to handle LOBs across different DBMS
is much more
portable (and reliably) than using the Clob()/Blob() meth
Hi,
> > I found that using getBinaryStream(), setBinaryStream(),
> > getCharacterStream()
> > and setCharacterStream() to handle LOBs across different DBMS
> > is much more
> > portable (and reliably) than using the Clob()/Blob() methods.
>
> According to JDBC 3.0 specifiction, those 4 methods
Thomas,
Thank you for your comment.
> I found that using getBinaryStream(), setBinaryStream(),
> getCharacterStream()
> and setCharacterStream() to handle LOBs across different DBMS
> is much more
> portable (and reliably) than using the Clob()/Blob() methods.
According to JDBC 3.0 specifict
"EBIHARA, Yuichiro" <[EMAIL PROTECTED]> writes:
> Using Large Objects may solve my issue but I have to note that a large
> object is not automatically deleted when the record referring to it is
> deleted.
The contrib/lo module can help with this.
regards, tom lane
---
EBIHARA, Yuichiro wrote on 22.06.2007 06:09:
It seems like PG JDBC driver CANNOT handle 'bytea' as BLOB nor 'text' as CLOB.
getBlob()/setBlob()/getClob()/setClob() can work with only Large Objects (at
least with
postgresql-8.1-405.jdbc3.jar).
org.postgresql.util.PSQLException: Bad Integer Z\27
Hi,
I found my understanding was incorrect.
> > > Is there any plan to support BLOB and CLOB in future releases?
> > >
> > Looking at the spec, and postgresql's implementation, I can't
> > see much reason you couldn't just use a domain to declare that
> > a bytea is a blob and varchar is a clo
Hi Scott,
Thank you for your comment.
> > Is there any plan to support BLOB and CLOB in future releases?
> >
> Looking at the spec, and postgresql's implementation, I can't
> see much reason you couldn't just use a domain to declare that
> a bytea is a blob and varchar is a clob.
That sounds
EBIHARA, Yuichiro wrote:
Hi,
I'm developing a software that supports several RDBMSs including PostgreSQL.
The software needs an ability to handle large objects and now it uses 'bytea'
datatype for binary
data and 'text' for text data.
But for portability, I'd rather use BLOB and CLOB defined
12 matches
Mail list logo
