Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Begin statement again

From: Michael Meskes <meskes(at)topsystem(dot)de>
To: andreas(dot)zeugswetter(at)telecom(dot)at (Zeugswetter Andreas)
Cc: pgsql-hackers(at)postgresql(dot)org (PostgreSQL Hacker)
Subject: Re: [HACKERS] Begin statement again
Date: 1998-03-25 14:49:14
Message-ID: 199803251449.PAA16530@gauss.topsystem.de (view raw or flat)
Thread:
Lists: pgsql-hackers
Zeugswetter Andreas writes:
> I meant: why is a transaction always open in an ecpg program

Because this is how it works with other embedded SQL systems too. I have
done quite some work with Oracle, and it always has the transaction open.

Keep in mind that there is no disconnect command. Instead you go out by
issuing a commit.

> Yes, but this is handeled implicitly by the backend even if the user does not say
> begin work;
> blabla
> commit work;
> In that sense every statement is atomic.
> 
> In a client server environment the implicit begin work; commit work; can save
> a lot of time since it saves 2 network roundtrips.
> And of course it would be bad practice if the user is forced to do commit work;
> and then for ease of programming and execution speed only does this every 100 statements.
> 
> What I am saying here is, that an ecpg program should be able to run with 
> autocommit mode on.  (Michael Meskes)

I tend to agree. But all embedded SQL programs I've seen so far only use
commit. I never saw one that issues a begin work since I stopped using
Ingres.

Michael

-- 
Dr. Michael Meskes, Project-Manager    | topsystem Systemhaus GmbH
meskes(at)topsystem(dot)de                    | Europark A2, Adenauerstr. 20
meskes(at)debian(dot)org                      | 52146 Wuerselen
Go SF49ers! Go Rhein Fire!             | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!                  | Fax: (+49) 2405/4670-10

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-03-25 14:52:19
Subject: Re: AW: [HACKERS] Re: PostgreSQL reference manual
Previous:From: Bruce MomjianDate: 1998-03-25 14:46:38
Subject: Re: [HACKERS] Feature: output index name in explain ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group