>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.
I am well accustomed to the deficiencies of Oracle. But in Oracle you don't have read locks,
and so a read only program does no harm if it only does one commit when it exits
(except maybe block the RBS if it did one small update).
Since postgresql does have read locks, such a program will lock all resources as time goes by,
if it does not do frequent commits. Not to speak of memory, that does not get freed.
>>
>>Keep in mind that there is no disconnect command. Instead you go out by
>>issuing a commit.
Hmmm ? you don't tell the backend when the program exits ?
> 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.
Try Informix, and you will love the difference and speed in these points.
The begin work statement is also a fundamental part of postgres. I simply would not hide it.
Andreas