with the driver. (Course, I've been using
PoolMan as the datasource to wrap the postgresql default connection rather than
using the datasource object, so I haven't been testing this myself, yet.)
On 26-Oct-2001 Barry Lind wrote:
Ned,
There really isn't a j2ee driver for postgres. If you
Robert,
What version of the driver and database are you using? I have code that
gets the update count back from executeUpdate(). So I suspect this may
be fixed in a more recent version.
thanks,
--Barry
Robert Dyas wrote:
Hi all,
I have been using the JDBC driver for a couple of months
The jdbc driver does not support updateable result sets. If you want to
update the data you need to do it the old fashioned way (i.e. use update
SQL statements).
thanks,
--Barry
Robinson wrote:
Hello,
I have a situation where I just want the changes to be made temporarily
in the
by the spec.
thanks,
--Barry
Ned Wolpert wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, I understand.
So, why are people talking about support for JDBC3 where JDBC2 support isn't
even there?
On 26-Oct-2001 Barry Lind wrote:
Ned,
It may or may not work. That file
Ned,
There really isn't a j2ee driver for postgres. If you build the j2ee
driver it is essentially the same as the j2se driver. So I don't see
any reason to confuse people by letting them think there really is a
difference by having two different java2 drivers to choose from on the
web
Mark,
Any help on moving the jdbc code base forward is more than welcome. In
briefly looking over your suggestions below they all seem fine to me.
(Of course the devil is in the details). I would also suggest looking
at http://lab.applinet.nl/postgresql-jdbc for a list of where we are
Per-Olof,
Thanks for the constructive feedback.
Let me try to answer your questions:
1. How is the driver compliance tests carried out? The test harness from
sun?
The sun test harness has been run. However the sun test harness is only
for jdbc2 + the enterprise extensions. As far as I
The patch is missing the corresponding fix for
jdbc1/DatabaseMetaData.java. Can you resubmit the patch with a fix for
both occurances of the problem? Otherwise the fix looks fine.
thanks,
--Barry
Bruce Momjian wrote:
Here is a patch for DatabaseMetaData to show precision properly. It is
is (and there probably
isn't an ideal solution), thus I feel we should stick with status quo
for 7.2 and deal with all of this in a few months after 7.2 is production.
thanks,
--Barry
Tom Lane wrote:
Barry Lind [EMAIL PROTECTED] writes:
If we can include the ANT libraries in our CVS then my
Per-Olof Norén wrote:
Hi all,
I have been listening to the discussions about Ant and the build system.
I think that the discussion is missing a point, which I will try to make
here :-)
1. Standard
The Ant build system is making its way to be a de facto standard for
(MST)
Sender: [EMAIL PROTECTED]
From: Ned Wolpert [EMAIL PROTECTED]
To: Barry Lind [EMAIL PROTECTED]
Subject: Re: [JDBC] [PATCHES] Ant configuration
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Two cents with of thought... :-)
On 18-Oct-2001 Barry Lind wrote:
* People with Java
I would suggest starting with the 7.1 drivers off of
jdbc.postgresql.org. The functionality they provide for
Blobs/LargeObjects matches the documentation you are using.
You can also try the 7.2 drivers that you can also download from
jdbc.postgresql.org. In these drivers the implementation
Andrew,
I think I see the problem. (It was the 'invalid large obj descriptor
(0)' message that clued me in). The LargeObject reference is only valid
within a transaction. Thus if you have autocommit turned on, you
basically can't use LargeObjects. Because as soon as the sql is
executed
know.
Barry Lind wrote:
Anyone can do that by submitting a patch. I don't see anything
special that needs to be done.
--Barry
Joseph Shraibman wrote:
Right. And a maintainer needs to make a jdbc3 direcotry and modifiy
the ant files to use it when it detects a jdk of 1.4+
Dave
Marko,
But it seems to me that Ant has a positive side too:
I agree that there are positive reasons to use Ant (that is why it was
done in the first place). It is just that in retrospect, I don't
believe the pluses outweigh the minuses.
* People with Java background probably know
This really doesn't have anything to do with 1.4. If you think you have
a bug, please send an email to the list with instructions on how to
reproduce (and a test case showing the problem that could be compiled
and run would be really great as well). Or even better get the source
code and
I don't like this patch. If anything I think we should remove the
dependency on ANT, not remove the dependency on make.
By requiring ANT, we provide yet another hurdle for someone wanting to
use JDBC with postgres. I would prefer that the build environment be
the same for the database as
Anyone can do that by submitting a patch. I don't see anything special
that needs to be done.
--Barry
Joseph Shraibman wrote:
Right. And a maintainer needs to make a jdbc3 direcotry and modifiy the
ant files to use it when it detects a jdk of 1.4+
Dave Cramer wrote:
What do you
It should be returning an Integer object. In a brief look at the source
code it seems to be doing the correct thing. What version are you using?
Also I noticed your example below:
System.out.println(The result is: + (String) obj);
This shouldn't work. You can't cast any random object
functions in PostgreSQL are called via a select statement.
Issue select your_custom_function() in a Statement or
PreparedStatement. Then get the result like any other select statement
via the ResultSet.
thanks,
--Barry
Oleg Lebedev wrote:
Hi,
I created a PL/pgSQL function, but can not
David,
This is a problem in the driver. I believe it is fixed in current
sources. Can you download the latest development build from
jdbc.postgresql.org and see if that works for you?
thanks,
--Barry
David Brownlee wrote:
(I'm not subscribed to the list, please cc directly in
Ben,
Cursors are supported. My guess as to your problem (since you didn't
send a full code example of what you are doing) is that you need to
issue multiple 'fetch' statements. Each fetch statement will return its
own result set. So when you have used up the results from one fetch
Mail like this doesn't help the situation any. Would you mind telling
us what version you are having problems with? Suppling a test case that
reproduces the problem would be better, and providing a patch that fixes
the problem would be best of all.
This is an open source project. Things
Dave,
I share your concerns about this functionality. In fact last month I
wrote the following in response to a patch to this functionality.
I wouldn't mind this being pulled out of the main code line for now and
moved to contrib until it becomes more robust.
Robert,
Thanks for the
Dave,
First off, are you running with autocommit turned off in JDBC? By
default autocommit is on, and thus your lock is removed as soon as it is
aquired.
Secondly, you don't need a table lock, you just need to lock the row
between the select and the update. You should use 'select for
OK, this is a known bug. It should be fixed in current sources. Try
using the 7.2 driver from the jdbc.postgresql.org website and see if
that works correctly for you. If you search the email archives you can
find a discussion on this bug.
thanks,
--Barry
David Siebert wrote:
It looks as
David,
Can you specify the exact error you are getting? along with the database
version, jdbc version and java version you are running? Also a test
case that demonstrates the problem would be very helpful as well.
thanks,
--Barry
David Siebert wrote:
I am having problems with
The subject pretty much says it all. I have updated the jdbc website to
contain more current information. It certainly could contain more
information, but my primary goal was to get it current. If you have any
suggestions, changes or additions please send them to the mail list.
thanks,
Since you are doing a select * without any where clause, postgres is
going to return the entire table back to the client all at once. The
client then needs to store the entire result in memory, thus you will
need enough memory to hold the entire table in memory.
A better way to do this in
No it does not.
thanks,
--Barry
jcooney wrote:
Does the 7.1-1.3 driver availalble on fastcrypt support JDBC 2.0 driver based
connection pooling?
I'm more than willing to look up the answer to this myself if someone can
point be towards some technical documentation.
Thanks,
jc
The jdbc driver is OS independent. It doesn't matter which platform the
driver is compiled on, it will run on any platform that supports a java
runtime.
As far as jdk1.2 vs jdk1.3 goes, a driver compiled by a 1.2 jdk will
work fine under jdk1.3. The code is identical for these two jdk
Matt,
Have you verified that this large object (id=12992) exists in your
database? (select distinct loid from pg_largeobject where loid = 12992)
If it doesn't, I think then the place to look is the code that you used
to insert the large objects as it would appear that code didn't do the
Dave,
The protocol for the clients to talk with the backend server doesn't
support the concept of a fetch size. When a query is executed it's
entire result is sent to the client. (You can explicitly work around
this by using cursors see the DECLARE and FETCH sql commands).
thanks,
--Barry
Alexaki,
I am unsure what you mean by very long transaction. A transaction is
defined by issueing a 'begin' statement, followed sometime later by a
'commit' or 'rollback'. Therefore a long transcation would imply a long
period of time between the begin and the commit or rollback. There is
Bruce,
This patch is fine.
thanks,
--Barry
Bruce Momjian wrote:
I noticed that jdbc1 getBoolean allows '1', while jdbc2 does not. The
following patch makes jdbc2 accept '1' also. Is this OK?
Index:
Peter,
Good question. There was a mail thread on this probably about six
months ago. IIRC this was done so that you could call getBoolean() on
an integer column. I think that some other database supported this and
they wanted to have postgres support it in the same way. I think that
is
this as a
problem.
Regards,
Ren? Pijlman
On Tue, 04 Sep 2001 10:40:36 -0700, Barry Lind wrote:
I would like to add one additional comment. In current sources the jdbc
driver detects (through a hack) that the server doesn't have multibyte
enabled and then ignores the SQL_ASCII return value
Larry,
Shouldn't your connection URL be:
jdbc:postgresql://localhost:5432/testdb
instead of
jdbc:postgresql://localhost:5432?database=testdb
thanks,
--Barry
Larry Rogers wrote:
Hi all,
I'm having trouble opening a database connection to a test database on a
fresh PostGreSQL 7.1.3
will be added to the Todo list. I'm under the
impression that the backend developers don't see this as a
problem.
Regards,
Ren? Pijlman
On Tue, 04 Sep 2001 10:40:36 -0700, Barry Lind wrote:
I would like to add one additional comment. In current sources the jdbc
driver detects (through a hack
Your recommendation to leave the behavior as is and change the
regression test is fine with me.
thanks,
--Barry
Rene Pijlman wrote:
The ConnectionTest test case in our own jdbc2 test suite fails
to set and get the transaction isolation level correctly. After
looking at the implementation
think it
is worth the hassle, and I can live with the existing format.
thanks,
--Barry
Dave Cramer wrote:
Well, my vote would be for a 2 space indent.
Dave
On Tue, 2001-09-04 at 16:59, Tom Lane wrote:
Barry Lind [EMAIL PROTECTED] writes:
I am OK with the style used for the C code. However
I believe this was done a while ago. (It looks like it was patched on
Aug 17 by a patch from Rene).
thanks,
--Barry
Bruce Momjian wrote:
Can someone tackles this and supply a patch?
Would some JDBC hacker develop a patch for the following issue? The
change is just barely large enough
Joseph,
In looking at this patch it looks OK, except for the following change:
! if (index=-rows.size())
--- 725,737
! if (index rows_size)
I haven't looked at the entire method, but the change you made seems
incorrect.
If you want this patch to be applied it
was removed from the database in 7.0 and from the
JDBC driver in 7.0.2. Therefore I don't think we should code for the
case of a 7.2 JDBC driver needing to support a 6.5 database.
thanks,
--Barry
Rene Pijlman wrote:
On Mon, 27 Aug 2001 22:57:13 -0700, Barry Lind wrote:
I do not know what
Dave,
There is a bug in this patch. In the rollback case, you have:
! ExecSQL(rollback; begin+getIsolationLevelSQL());
You are missing a semicolon after the begin.
thanks,
--Barry
Dave Cramer wrote:
Here is a revised patch with Barry's suggestions implemented
Dave
I agree that this is needed. In fact I know Bruce wants to do something
in this area. In fact he sent out a few months ago a sample of the code
after it had been cleaned up by some tool. At the time no one seemed to
be very interested. Going forward for 7.2 I think now is the time that
is the proper encoding for your database
For completeness, I quote the answer Barry Lind gave yesterday.
[the driver] asks the server what character set is being used
for the database. Unfortunatly the server only knows about
character sets if multibyte support is compiled
Kovács Péter wrote:
the driver what character set the backend is sending us? Can't
it ask the backend dynamically?
This is what it actually does, isn't it? (Based on what I usually see in the
trace output on the backend.) I tested a unicode database with varchar(255)
fields and hungarian
the last year. For example since 7.1 came out in April 2001, this would
mean supporting 7.0 until April 2002. And if 7.2 when production in
October 2001, then 7.1 should be supported until October 2002.
thanks,
--Barry
Tom Lane wrote:
Barry Lind [EMAIL PROTECTED] writes:
The multiple
Is there a reason you are not using getBinaryStream()? You can't read a
binary file with and AsciiStream.
thanks,
--Barry
Isabelle Therrien wrote:
Hi
I've seen a couple of discussion about this subject, and I wonder if you
could help me finding a workaround for my problem too.
I work
Dave,
The multiple statements in one call is there for performance reasons.
Please don't remove it entirely since it works fine in 7.1 and 7.2.
Instead your fix should be conditional based on server version:
if (autoCommit)
ExecSQL(end);
else {
ifMinumumServerVersion(7.1) {
Ricardo,
Is your database compiled for multibyte support? And what character set
is the database you are connecting to created with? (to get the
database character set do a 'psql -l'). If the answer to the first
question is no or the answer to the second question is 'SQL_ASCII', then
only
but no real info on what it is, or no mention of it in the main types page.
Anyway, I think I'm fine for now, stipping the null chars from my data.
Tom.
On Tue, Aug 28, 2001 at 09:17:19PM -0700, Barry Lind wrote:
Thomas,
The text datatypes in postgres (i.e. char, varchar, text) do not support
Yes I have seen this behavior as well (first run has many failures, but
later ones succeed). One reason that I noticed had to do with test
setup code. Many of the tests do the following:
drop table foobar;
create table foobar (...);
The first time this is run on a clean database the drop
it.
Cheers,
Tom.
On Tue, Aug 28, 2001 at 12:55:19PM -0700, Barry Lind wrote:
Thomas,
This is doing exactly what it is supposed to according to the JDBC Spec.
In fact there are a bunch of other '{X }' things that the Spec
defines that it should also be handling.
thanks,
--Barry
Thomas
in postgresql. I found that the query is being truncated
and is not fully making it to the backend, therefore I'm getting the
Unterminated string error. I'll have a look into why and report back if
I find anything.
Cheers,
Tom.
On Tue, Aug 28, 2001 at 12:56:50PM -0700, Barry Lind wrote:
Thomas
No this is not the way to do this. Elsewhere when the driver has
different functionality/requirements for JDBC1 vs JDBC2 this is
impelmented via subclassing (see the jdbc1 and jdbc2 packages). That
pattern should be followed here, not the kludgy fake ifdef support
provided by configure.
Rene,
I see your statements below as incorrect:
The intended behaviour is to send a set of update/insert/delete/DDL
statements in one round trip to the database. Unfortunately,
this optional JDBC feature cannot be implemented correctly with
PostgreSQL, since the backend only returns the
I looked at the patch and it looks fine. As for what fqp and hfr stand
for I don't have a clue. I was looking through the fe/be protocol
documentation and think I might have a clue about what they are being
used for.
thanks,
--Barry
Anders Bengtsson wrote:
Hi,
Attached is my attempt to
What exactly is the behaviour of the backend in that scenario?
Does it commit every separate SQL statement in the
semicolon-separated list, or does it commit the list as a whole?
Does it abort processing the statement list when an error occurs
in one statement? And if it continues, does
So going forward, whose responsibility is it to maintain this file? Is
it the responsibility of the person submitting the patch (i.e. each
patch should contain an update to CHANGELOG), or is it the
responsibility of the person applying the patch?
thanks,
--Barry
Bruce Momjian wrote:
Bruce,
a good option in itself, but outside of my original 'catch'
line, its all I got.
What's your thoughts? Do you see the need for the functionality? Do you have
a solution that I need?
On 22-Aug-2001 Barry Lind wrote:
I am assuming that this would be a new function in the server.
Therefore
I am assuming that this would be a new function in the server.
Therefore this wouldn't be jdbc specific and would be available to all
client interfaces. I don't see what this really has to do with JDBC.
thanks,
--Barry
Ned Wolpert wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
FYI -- JDBC questions should go to the pgsql-jdbc mail list.
As for your problem, I think probably the easiest workaround is to
explicitly cast your constants. Assuming you are using
PreparedStatements, a statement of the following form should work:
select * from foo
where bar = ?::numeric
released
code ie. 7.1.2 or 7.1.3.
thanks,
--Barry
Bruce Momjian wrote:
* Barry Lind [EMAIL PROTECTED] wrote:
|
|
| Now having said that, there isn't any reason that the jdbc code can't
| be released more frequently than the server. But without a lot more
Maybe there could be sub releases
Yes this does appear to be a bug. Can you submit a patch to
[EMAIL PROTECTED] with the fix. If you don't have time, let
me know and I will submit the patch.
thanks,
--Barry
Jason Orendorff wrote:
Reply-To: sender
Hi. I'm having a problem with the JDBC driver. It's excellent for
the
Alexander,
Hello Barry,
First of all, it is possible that this patch is no needed to be applied.
I will try to explain the problem:
Some times ago I have to insert some texts into filed with type text.
Everything was great until I have read the log file of postges: I was
shocked.
for Blob/Clob support Barry Lind
wrote about a couple of days ago, it wasn't clear what needed to
be done. Investigating and documenting the conformance level and
known deficiencies seemed like a good place to start.
Regards,
René Pijlman
---(end of broadcast
. (This is how Oracle deals with
similar issues in its code base). This parameter could then be set
either in the JDBC URL (i.e.
jdbc:postgresql://localhost:5432:template1?compatible=7.1) or passed
explicily in the connect() method.
thanks,
--Barry
Tom Lane wrote:
Barry Lind [EMAIL PROTECTED
GUC is how this type of stuff is controlled on the server, but I don't
know of any examples where it controlls client only functionality. Why
would you want parameters on the server that the server doesn't use?
thanks,
--Barry
Bruce Momjian wrote:
If people feel that backwards compatibiliy
Anders,
What aspects of BLOB support do you consider broken? Are these aspects
that are broken in the JDBC layer or are 'broken' at the server layer?
thanks,
--Barry
Anders Bengtsson wrote:
On Wed, 1 Aug 2001, Rene Pijlman wrote:
Hello,
I read in comp.lang.java.databases that help is
I actually consider the biggest problem the fact the the 'official'
postgres jdbc website is very much out of date
(http://jdbc.postgresql.org). (it doesn't even have the 7.1 drivers).
I feel that either someone needs to maintain this page; or someone needs
to create a new website and get
Examples please? We need to know what is broken/missing in order for it
to be fixed. I know there are people out there who would be glad to fix
bugs in the JDBC driver if they know about them. Please post the
problems you encountered to the jdbc mail list.
thanks,
--Barry
Ricardo Maia
Please send us all of the issues you have or know about. Just providing
examples of some of the problems will only get fixes for some of the
problems. What would be really useful is a list of all the issues you
know about. That way they can end up on the TODO list and get addressed.
The attached patch fixes problems with the JDBC driver handling long
null terminated strings. The FE/BE protocol sends in some cases null
terminated strings to the client. The docs for the FE/BE protocol state
that there is no limit on the size of a null terminated string sent to
the client
Tony Grant wrote:
On 04 May 2001 11:40:48 -0400, Tom Lane wrote:
But a non-MULTIBYTE backend doesn't even have the concept of setting
the encoding --- it will always just report SQL_ASCII.
What kind of error message does createdb -E LATIN1 give on a non
MULTIBYTE backend?
Maybe
Since Java uses unicode (ucs2) internally for all Strings, the jdbc code
always needs to do character set conversions for all strings it gets
from the database. In the 7.0 drivers this was done by assuming the
database was using the same character set as the default on the client,
which is
Jerry,
There are a couple of things going on here. First you really can't use
a postgres char/varchar/text datatype to store/retrieve binary
information with jdbc. (See a message I just posted to the jdbc mail
list explaining character set conversions in the 7.1 jdbc drivers).
So the
My comments on this thread are:
1) Having java as an available stored procedure language would be
great. I am not sure if that is what is being proposed or not, but it
seems to be a necesary step if you are talking about running java on the
database server.
2) The idea of extending the
79 matches
Mail list logo
