From: Michael Meskes <meskes@topsystem.de>
To: jwieck@debis.com
Cc: pgsql-hackers@postgresql.org
Subject: Re: AW: [HACKERS] Begin statement again
Date: Thu, 26 Mar 1998 09:12:20 +0100 (MEZ)
Message-ID: <199803260812.JAA19968@gauss.topsystem.de> (raw)
In-Reply-To: <m0yHt6r-000BFRC@orion.SAPserv.Hamburg.dsh.de>
Jan Wieck writes:
> I'm not that familiar with the C level of Oracle connections.
> But I used oratcl from Tom Poindexter sometimes and that has
> a AUTOCOMMIT ON/OFF statement that sets the autocommit flag
> in the library routines somewhere. Doesn't embedded SQL use
> the same libraries to connect to oracle that oratcl uses?
Don't know.
> Anyway - ecpg could work around. It can manage an autocommit
> flag and an in_trans status by itself. When autocommit is OFF
> and in_trans is false, it sends down a 'BEGIN TRANSACTION'
> right before the next query and sets in_trans to true.
> Later, when PostgreSQL responds 'COMMIT' from a query, it
> sets in_trans back to false and we have the behaviour of the
> AUTOCOMMIT. This way, a program that doesn't explicitly set
> autocommit to off might sometimes issue a COMMIT that results
> in an empty BEGIN/COMMIT sequence sent down to the backend -
> not too bad IMHO. As soon as a program requires real
Wait a moment. This is almost as it is handled currently. ecpg issues a
'BEGIN TRANSACTION' before the next statement if commited (as the variable
is called) is set to TRUE. Then it sets commited back to FALSE. Issuing a
COMMIT sets it back to TRUE.
> transactions, it sets autocommit to false and has (from the
> embedded SQL programmers point of view) total Oracle
> compatibility. And as long as autocommit is ON, there are no
Oracle compatibility means exactly the behaviour we currently have. BEGIN
TRANSACTION is issued automatically. COMMIT has to be called by hand. But
what we were talking about is forcing both to be called by the programmer.
> open locks laying around since ecpg doesn't send 'BEGIN
> TRANSACTION' and PostgreSQL's default is somewhat like
> autocommit too.
> ...
> Isn't EOF information enough? Must a client say BYE?
No, it need not. But it would be nice if it does, wouldn't it?
Michael
--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
meskes@topsystem.de | Europark A2, Adenauerstr. 20
meskes@debian.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: meskes@topsystem.de, jwieck@debis.com
Subject: Re: AW: [HACKERS] Begin statement again
In-Reply-To: <199803260812.JAA19968@gauss.topsystem.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox