RE: [HACKERS] Begin statement again

I agree with BEGIN/END being used for PL/pgSQL. But that means I have to
add it to ecpg to start a block of PL/pgSQL, e.g. to call a stored
procedure in ORACLE I need PL/SQL in C.

AFAIK there is no transaction start command in SQL standard anymore.
Just issue commit and your transaction is flushed. So either I have to
remove that feature and go back to explicit transaction start commands
or BEGIN WORK resp. BEGIN TRANSACTION are useless.

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

> -----Original Message-----
> From: Zeugswetter Andreas [SMTP:andreas(dot)zeugswetter(at)telecom(dot)at]
> Sent: Friday, March 13, 1998 1:50 PM
> To: 'Michael Meskes'
> Cc: 'pgsql-hackers(at)hub(dot)org'
> Subject: AW: [HACKERS] Begin statement again
>
> I think we should depreciate the BEGIN/END keywords in SQL to allow
> them
> to be used for the new PL/SQL. So definitely leave them out of ecpg
> now.
> Only accept BEGIN WORK and BEGIN TRANSACTION. (do a sequence of commit
> work; begin work)
> BTW.: why is a transaction always open ? A lot of programs would never
> need a
> transaction. Is it because of cursors ?
>
> Andreas
>
>
> Michael Meskes wrote:
> Forget about my last question. I found the begin call in ecpglib.c. It
> doesn
> what you expect from a embedded SQL preprocessor, it starts a new
> transaction as soon as one ends. Nevertheless I thought about
> accepting
> explicit begin calls in the new version. But they will always generate
> a
> warning message as the code's always inside a transaction. So I could
> as
> well accept the begin call but not give it to the backend.
>
>
>