On Tue, 10 Sep 2002, Barry Lind wrote:
> Yes I can check the server version on connect. In fact that is what the
> driver already does. However I can't check the version and then based
> on the version call set autocommit true in one round trip to the server.
> Since many people don't use c
Curt,
Yes I can check the server version on connect. In fact that is what the
driver already does. However I can't check the version and then based
on the version call set autocommit true in one round trip to the server.
Since many people don't use connection pools, I am reluctant to add
Curt Sampson wrote:
> On Tue, 10 Sep 2002, Bruce Momjian wrote:
>
> > Do we want to say "With autocommit off, SET will be in it's own
> > transaction if it appears before any non-SET command", and "SETs are
> > rolled back except if autocommit off and they appear before any
> > non-SET"?
>
> Not
On Tue, 10 Sep 2002, Bruce Momjian wrote:
> Do we want to say "With autocommit off, SET will be in it's own
> transaction if it appears before any non-SET command", and "SETs are
> rolled back except if autocommit off and they appear before any
> non-SET"?
Not really, I don't think.
But I'm sta
On Tue, 10 Sep 2002, Barry Lind wrote:
> I am waiting for this thread to conclude before deciding exactly what to
> do for the jdbc driver for 7.3. While using the 'set autocommit true'
> syntax is nice when talking to a 7.3 server, the jdbc driver also needs
> to be backwardly compatible with 7
On Tuesday 10 September 2002 09:55 pm, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > That seems messy. What you are saying is that if autocommit is off,
> > then in:
> >
> > SET x=1;
> > UPDATE ...
> > SET y=2;
> > ROLLBACK;
> >
> > that the x=1 doesn't get rolle
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > That seems messy. What you are saying is that if autocommit is off,
> > then in:
>
> > SET x=1;
> > UPDATE ...
> > SET y=2;
> > ROLLBACK;
>
> > that the x=1 doesn't get rolled back bu the y=2 does?
>
> Yes, if you
Bruce Momjian <[EMAIL PROTECTED]> writes:
> That seems messy. What you are saying is that if autocommit is off,
> then in:
> SET x=1;
> UPDATE ...
> SET y=2;
> ROLLBACK;
> that the x=1 doesn't get rolled back bu the y=2 does?
Yes, if you weren't in a transaction at the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Does anyone see any cases where it's important for SET to start
> >> a transaction? (Of course, if you are already *in* a transaction,
> >> the SET will be part of that transaction. The question is whether
> >>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Does anyone see any cases where it's important for SET to start
>> a transaction? (Of course, if you are already *in* a transaction,
>> the SET will be part of that transaction. The question is whether
>> we want SET to trigger an im
Tom Lane wrote:
> An example of how this would simplify life: consider the problem of
> a client that wants to ensure autocommit is on. A simple
> SET autocommit TO on;
> doesn't work at the moment: if autocommit is off, then you'll need
> to issue a COMMIT as well to get out of the implici
I am waiting for this thread to conclude before deciding exactly what to
do for the jdbc driver for 7.3. While using the 'set autocommit true'
syntax is nice when talking to a 7.3 server, the jdbc driver also needs
to be backwardly compatible with 7.2 and 7.1 servers. So it may just be
easier to
ruce Momjian
> Cc: Barry Lind; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [JDBC] [HACKERS] problem with new autocommit config
> parameter and jdbc
>
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Barry Lind wrote:
> >> How should client in
Curt Sampson <[EMAIL PROTECTED]> writes:
> Probably the driver should be changed for 7.3 just to use the server's
> SET AUTOCOMMIT functionality
That should happen eventually, IMHO, but I am not going to tell the JDBC
developers that they must make it happen for 7.3. They've already got a
pi
On Mon, 9 Sep 2002, Tom Lane wrote:
> If autocommit=off really seriously breaks JDBC then I don't think a
> simple SET command at the start of a session is going to do that much
> to improve robustness. What if the user issues another SET to turn it
> on?
You mean, to turn it off again? The dri
t; Sincerely,
>
> Daryl.
>
>
>
>>-Original Message-
>>From: Tom Lane [mailto:[EMAIL PROTECTED]]
>>Sent: Monday, September 09, 2002 2:54 PM
>>To: Bruce Momjian
>>Cc: Barry Lind; [EMAIL PROTECTED];
>>[EMAIL PROTECTED]
>>Subject: Re:
Yes it is possible, but according to the jdbc spec, a new connection in
jdbc is always initialized to autocommit=true. So jdbc needs to ignore
whatever the current server setting is and reset to autocommit=true.
--Barry
snpe wrote:
> On Saturday 07 September 2002 02:55 am, Bruce Momjian wrote
snpe wrote:
> On Saturday 07 September 2002 02:55 am, Bruce Momjian wrote:
> > Barry Lind wrote:
> > > Haris,
> > >
> > > You can't use jdbc (and probably most other postgres clients) with
> > > autocommit in postgresql.conf turned off.
> > >
> > > Hackers,
> > >
> > > How should client interfaces
On Saturday 07 September 2002 02:55 am, Bruce Momjian wrote:
> Barry Lind wrote:
> > Haris,
> >
> > You can't use jdbc (and probably most other postgres clients) with
> > autocommit in postgresql.conf turned off.
> >
> > Hackers,
> >
> > How should client interfaces handle this new autocommit feat
19 matches
Mail list logo
