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-
> Fro
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 dislik
What I have is a connection pool.
I initially grab 2 connections, one primary one secondary.
If the insert fails on the primary connection I try the
secondary, if it fails I simply delete the 2 I have and grab
2 more from the connection pool. After creating the new ones
I have never seen it fai
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
Chris,
I had the same problem on the insert side and thought it went away but
it is back and I am convinced it is related to more than one thread using
the same connection at the same time. What I have done as a work around
in the interim ( until I write my own connection manager class ) is ca
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 t
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 offendin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Dave Cramer
Sent: September 4, 2001 1:21 PM
To: [EMAIL PROTECTED]
Subject: Re: [JDBC] Read transactions don't work on 7.0.x db's 2nd patch
Here is a revised patch with Barry's suggestions implemented
Da
At 12:41 PM 9/5/2001, Joseph Shraibman wrote:
>new patch:
There still seems to be an error with the same if-block.
! if (index>=-rows.size())
! internalIndex=rows.size()+index;
becomes
! if (index > -rows_size)
! internalIndex = rows_size+index;
Note that the original
>
>
> 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 ma
On Tue, Sep 04, 2001 at 04:59:20PM -0400, 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 disagree with this, because
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
Patch applied. Thanks.
> Hi,
>
> Attached is a patch for JDBC's getColumn() function that was broken /
> flawed in the following ways:
>
> 1. Only returned columns that had a default value defined, rather than all
> columns in a table
> 2. Used 2 * N + 1 queries to find out attributes, comm
Barry, I just applied this patch and a few others. Let me know if they
are OK.
> 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
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
> > spac
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 commi
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.
>
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
21 matches
Mail list logo
