On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 06:11 pm, Stephan Szabo wrote:
>
> > I again am not sure I understand, are you saying that under serializable
> > select should start a transaction but it shouldn't under read committed?
> > That seems like a bad idea to me, either
On Wednesday 11 September 2002 06:11 pm, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > On Wednesday 11 September 2002 02:55 pm, Stephan Szabo wrote:
> > > On Wed, 11 Sep 2002, snpe wrote:
> > > > If decision (transaction or not) is after parser (before execute)
> > > > this isn't pr
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 02:55 pm, Stephan Szabo wrote:
> > On Wed, 11 Sep 2002, snpe wrote:
> > >
> > > If decision (transaction or not) is after parser (before execute) this
> > > isn't problem.
> > > I don't know when postgresql make decision, but that
On Wednesday 11 September 2002 02:55 pm, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > On Wednesday 11 September 2002 03:14 am, Stephan Szabo wrote:
> > > On Wed, 11 Sep 2002, snpe wrote:
> > > > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > > > On Wed, 11 Sep 2
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 02:38 pm, Rod Taylor wrote:
> > > > > Why rollback.This is error (typing error).Nothing happen.
> > > > > I think that we need clear set : what is start transaction ?
> > > > > I think that transaction start with change data in da
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 03:14 am, Stephan Szabo wrote:
> > On Wed, 11 Sep 2002, snpe wrote:
> > > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > > On Wed, 11 Sep 2002, snpe wrote:
> > > > > yes, we're going around in circles.
> > > >
On Wednesday 11 September 2002 02:38 pm, Rod Taylor wrote:
> > > > Why rollback.This is error (typing error).Nothing happen.
> > > > I think that we need clear set : what is start transaction ?
> > > > I think that transaction start with change data in database
> > > > (what don't change data this
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 04:58 am, Stephan Szabo wrote:
> > On Wed, 11 Sep 2002, snpe wrote:
> > > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > > On Wed, 11 Sep 2002, snpe wrote:
> > > > > yes, we're going around in circles.
> > > >
On Wednesday 11 September 2002 03:14 am, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > On Wed, 11 Sep 2002, snpe wrote:
> > > > yes, we're going around in circles.
> > > >
> > > > Ok.I agreed (I think because Oracle
> > > Why rollback.This is error (typing error).Nothing happen.
> > > I think that we need clear set : what is start transaction ?
> > > I think that transaction start with change data in database
> > > (what don't change data this start not transaction.
> >
> > Another interesting case for a sel
On Wednesday 11 September 2002 04:58 am, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > On Wed, 11 Sep 2002, snpe wrote:
> > > > yes, we're going around in circles.
> > > >
> > > > Ok.I agreed (I think because Oracle
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > On Wed, 11 Sep 2002, snpe wrote:
> > > yes, we're going around in circles.
> > >
> > > Ok.I agreed (I think because Oracle do different)
> > > Transaction start
> > > I type invalid command
> > >
On Tue, 2002-09-10 at 21:44, Curt Sampson wrote:
> But there were some issues with rolling back and SET commands,
> weren't there? I remember a long discussion about this that I'm
> not sure I want to go back to. :-)
So.. Unless explicitly requested, a SET command should have immediate
effect?
On Tue, 10 Sep 2002, Tom Lane wrote:
> As of CVS tip, SET commands *do* initiate transactions
> if you have autocommit off. By your reading of Date, this is not
> spec compliant for certain SET variables: a SET not already within
> a transaction should not start a transaction block, at least for
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > On Wed, 11 Sep 2002, snpe wrote:
> > > yes, we're going around in circles.
> > >
> > > Ok.I agreed (I think because Oracle do different)
> > > Transaction start
> > > I type invalid command
> > >
On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > yes, we're going around in circles.
> >
> > Ok.I agreed (I think because Oracle do different)
> > Transaction start
> > I type invalid command
> > I correct command
> > I get error
> >
> > Why.If i
On Wed, 11 Sep 2002, snpe wrote:
> yes, we're going around in circles.
>
> Ok.I agreed (I think because Oracle do different)
> Transaction start
> I type invalid command
> I correct command
> I get error
>
> Why.If is it transactin, why I get error
> I want continue.
> I am see this error with JD
On Wednesday 11 September 2002 01:25 am, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > On Tuesday 10 September 2002 11:50 pm, Stephan Szabo wrote:
> > > On Tue, 10 Sep 2002, snpe wrote:
> > > > On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> > > > > What if it's a selec
On Wed, 11 Sep 2002, snpe wrote:
> On Tuesday 10 September 2002 11:50 pm, Stephan Szabo wrote:
> > On Tue, 10 Sep 2002, snpe wrote:
> > > On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> > > > What if it's a select for update? IF that failed because of a timout
> > > > on a lock, sh
On Tuesday 10 September 2002 11:50 pm, Stephan Szabo wrote:
> On Tue, 10 Sep 2002, snpe wrote:
> > On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> > > What if it's a select for update? IF that failed because of a timout
> > > on a lock, shouldn't the transaction fail? Or a select i
On Tue, 10 Sep 2002, snpe wrote:
> On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> > What if it's a select for update? IF that failed because of a timout on a
> > lock, shouldn't the transaction fail? Or a select into? Either of those
> > should make a transaction fail, and they
On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> On Tue, 10 Sep 2002, Stephan Szabo wrote:
> > > > > > It starts a transaction, failes the first command and goes into
> > > > > > the error has occurred in this transaction state. Seems like
> > > > > > reasonable behavior.
> > > > >
>
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
On Tue, 10 Sep 2002, Stephan Szabo wrote:
> On Tue, 10 Sep 2002, scott.marlowe wrote:
>
> > On Tue, 10 Sep 2002, Stephan Szabo wrote:
> >
> > > > > > > It starts a transaction, failes the first command and goes into the
> > > > > > > error has occurred in this transaction state. Seems like reas
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
On Tue, 10 Sep 2002, scott.marlowe wrote:
> On Tue, 10 Sep 2002, Stephan Szabo wrote:
>
> > > > > > It starts a transaction, failes the first command and goes into the
> > > > > > error has occurred in this transaction state. Seems like reasonable
> > > > > > behavior.
> > > > >
> > > > > Select
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
On Tue, 10 Sep 2002, Stephan Szabo wrote:
> > > > > It starts a transaction, failes the first command and goes into the
> > > > > error has occurred in this transaction state. Seems like reasonable
> > > > > behavior.
> > > >
> > > > Select command don't start transaction - it is not good
> > >
> > > > It starts a transaction, failes the first command and goes into the
> > > > error has occurred in this transaction state. Seems like reasonable
> > > > behavior.
> > >
> > > Select command don't start transaction - it is not good
> >
> > I think you need more justification than "it is not
Curt Sampson <[EMAIL PROTECTED]> writes:
> From Date's _A Guide to the SQL Standard_ (Fourth Edition):
> ...
> The following SQL statements are _not_ transaction-initiating:
> CONNECT
> SET CONNECTION
> DISCONNECT
> SET SESSION AUTHORIZATION
> SET CATALOG
>
On Tuesday 10 September 2002 04:16 am, Stephan Szabo wrote:
> On Tue, 10 Sep 2002, snpe wrote:
> > On Tuesday 10 September 2002 03:05 am, Stephan Szabo wrote:
> > > On Tue, 10 Sep 2002, snpe wrote:
> > > > On Monday 09 September 2002 11:03 pm, Rod Taylor wrote:
> > > > > On Mon, 2002-09-09 at 17:0
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:
> snpe <[EMAIL PROTECTED]> writes:
>
> > snpe> select * from org_ba;
> > ERROR: relation org_ba does not exists
> > snpe> select * from org_ban;
> > ERROR: current transactions is aborted, queries ignored until end of
> > transaction block
>
> Um, what's wrong
snpe <[EMAIL PROTECTED]> writes:
> I'm use 'autocommit=false' and have problem with psql
> When any commnad is lost, then next commnad get error for transactions
> (simple select command).BTW
> snpe> select * from org_ba;
> ERROR: relation org_ba does not exists
> snpe> select * from org_ban;
> E
On Tue, 10 Sep 2002, snpe wrote:
> On Tuesday 10 September 2002 03:05 am, Stephan Szabo wrote:
> > On Tue, 10 Sep 2002, snpe wrote:
> > > On Monday 09 September 2002 11:03 pm, Rod Taylor wrote:
> > > > On Mon, 2002-09-09 at 17:04, snpe wrote:
> > > > > I'm use 'autocommit=false' and have problem
On Tuesday 10 September 2002 03:05 am, Stephan Szabo wrote:
> On Tue, 10 Sep 2002, snpe wrote:
> > On Monday 09 September 2002 11:03 pm, Rod Taylor wrote:
> > > On Mon, 2002-09-09 at 17:04, snpe wrote:
> > > > I'm use 'autocommit=false' and have problem with psql
> > > > When any commnad is lost,
On Tue, 10 Sep 2002, snpe wrote:
> On Monday 09 September 2002 11:03 pm, Rod Taylor wrote:
> > On Mon, 2002-09-09 at 17:04, snpe wrote:
> > > I'm use 'autocommit=false' and have problem with psql
> > > When any commnad is lost, then next commnad get error for transactions
> > > (simple select co
On Monday 09 September 2002 11:03 pm, Rod Taylor wrote:
> On Mon, 2002-09-09 at 17:04, snpe wrote:
> > I'm use 'autocommit=false' and have problem with psql
> > When any commnad is lost, then next commnad get error for transactions
> > (simple select command).BTW
> >
> > snpe> select * from org_ba
On Mon, 2002-09-09 at 17:04, snpe wrote:
> I'm use 'autocommit=false' and have problem with psql
> When any commnad is lost, then next commnad get error for transactions
> (simple select command).BTW
>
> snpe> select * from org_ba;
> ERROR: relation org_ba does not exists
> snpe> select * from o
On Monday 09 September 2002 08:53 pm, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Barry Lind wrote:
> >> How should client interfaces handle this new autocommit feature? Is it
> >> best to just issue a set at the beginning of the connection to ensure
> >> that it is always on?
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Barry Lind wrote:
>> How should client interfaces handle this new autocommit feature? Is it
>> best to just issue a set at the beginning of the connection to ensure
>> that it is always on?
> Yes, I thought that was the best fix for apps that can't dea
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
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 feature? Is it
> best to just issue a set at the beginning of the connection to
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 feature? Is it
best to just issue a set at the beginning of the connection to ensure
that it is always on?
thank
Hello Barry,
JDBC driver must find autocommit (off or on) and set autoCommit field
when open connection.
regards
On Friday 06 September 2002 06:52 pm, Barry Lind wrote:
> Haris,
>
> You can't use jdbc (and probably most other postgres clients) with
> autocommit in postgresql.conf turned off.
>
>
45 matches
Mail list logo
