The obvious question is whether the PERL-script is also executing in one
transaction. If it is not, we're cheating setting autocommit off in the
JDBC-test app. (I did not look at the code, since I am not familiar with the
PGSQL's PERL-interface anyway.)
Peter
-Original Message-
From:
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
On Tue, 4 Sep 2001, Bruce Momjian wrote:
Can people tak a look at that and see if they like it? I will work on
astyle to find a format that matches the main code indenting.
If you like it, I will indent just after we go beta.
Looks great!
I only noticed two things that I sort of disliked.
t.r.
thank you very much for this information...while i suppose you're right that
it's not as good as a fix, it is much better than the brick wall that i've
been facing (my app cannot be shipped in its current state). your
workaround should be relatively easy to implement and i can't argue with
I installed FFJ3.0 on a RH7.0, jdk1.3.1 machine.
I followed the instructions for installing jdbc drivers and at the test
stage I got an error message: Unable to perform action, null
However, in the Output Window (on top of which the error window came up) I
have 4 lines that prove connection to
follow-up question - you say that if you get one exception, you try the
insert with another connection...if that doesn't work you delete the
existing connections and get new ones...
i must be missing something - why wouldn't using the second connection
always work? if you get rid of the
Barry Lind wrote:
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.
Patch applied and files added. Thanks.
Attached is a patch for current CVS, consisting of a cvs diff -c
for the changed files and a few new files:
- test/jdbc2/BatchExecuteTest.java
- util/MessageTranslator.java
- jdbc2/PBatchUpdateException.java
As an aside, is this the best way to
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 would like the
following additional step done for the java code: replace all tabs with
spaces.
I
Joseph Shraibman [EMAIL PROTECTED] writes:
Barry Lind wrote:
If you want this patch to be applied it should be sent to the
pgsql-patches mail list.
I thought that jdbc stuff was preferred to be on the jdbc list.
I guess not.
Well, patches are patches, and it's easier for the committers to
Rene,
This writeup looks good. As for your two followup questions:
1) I agree with your opinion on the select issue. Since selects are
the only way to call functions and functions could themselves be doing
inserts/updates, to not allow selects is a bad idea IMHO.
2) The 8K limitation was
Barry Lind wrote:
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.
Oops! Thanks
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
Patch applied and file added. Thanks.
Hi,
Attached is my attempt to clean up the horrors of the ExecSQL() method in
the JDBC driver.
I've done this by extracting it into a new method object called
QueryExecutor (should go into org/postgresql/core/) and then taking it
apart into
14 matches
Mail list logo
