Re: AW: [HACKERS] Begin statement again - Mailing list pgsql-hackers

From Michael Meskes
Subject Re: AW: [HACKERS] Begin statement again
Date
Msg-id 199803260812.JAA19968@gauss.topsystem.de
Whole thread Raw
In response to Re: AW: [HACKERS] Begin statement again  (jwieck@debis.com (Jan Wieck))
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Frank Ridderbusch
Date:
Subject: [HACKERS] string.h and strings.h in ecpg
Next
From: Michael Meskes
Date:
Subject: Re: AW: AW: [HACKERS] Begin statement again