pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedAW: [HACKERS] Begin statement again
14+ messages / 8 participants
[nested] [flat]
* AW: [HACKERS] Begin statement again
@ 1970-01-01 00:00 Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
1998-03-13 12:43 ` Re: AW: [HACKERS] Begin statement again Jan Wieck <jwieck@debis.com>
0 siblings, 1 reply; 14+ messages in thread
From: Zeugswetter Andreas @ 1970-01-01 00:00 UTC (permalink / raw)
To: 'Michael Meskes' <meskes@topsystem.de>; +Cc: 'pgsql-hackers@hub.org' <pgsql-hackers@hub.org>
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.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: AW: [HACKERS] Begin statement again
1970-01-01 00:00 AW: [HACKERS] Begin statement again Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
@ 1998-03-13 12:43 ` Jan Wieck <jwieck@debis.com>
1998-03-25 03:43 ` Re: AW: [HACKERS] Begin statement again Vadim B. Mikheev <vadim@sable.krasnoyarsk.su>
0 siblings, 1 reply; 14+ messages in thread
From: jwieck@debis.com @ 1998-03-13 12:43 UTC (permalink / raw)
To: andreas.zeugswetter@telecom.at; +Cc: meskes@topsystem.de; pgsql-hackers@hub.org
Andreas wrote:
>
> 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 ?
BEGIN/END in PL/SQL and PL/pgSQL doesn't mean transactions!
It's just to group statements to a block. You cannot commit
something inside a PostgreSQL function. All changes made by a
function are covered by the statements transaction or the
upper transaction block.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: AW: [HACKERS] Begin statement again
1970-01-01 00:00 AW: [HACKERS] Begin statement again Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
1998-03-13 12:43 ` Re: AW: [HACKERS] Begin statement again Jan Wieck <jwieck@debis.com>
@ 1998-03-25 03:43 ` Vadim B. Mikheev <vadim@sable.krasnoyarsk.su>
1998-03-25 06:16 ` Re: AW: [HACKERS] Begin statement again David Gould <dg@illustra.com>
1998-03-25 09:36 ` Re: AW: [HACKERS] Begin statement again Jan Wieck <jwieck@debis.com>
0 siblings, 2 replies; 14+ messages in thread
From: Vadim B. Mikheev @ 1998-03-25 03:43 UTC (permalink / raw)
To: Jan Wieck <jwieck@debis.com>; +Cc: Zeugswetter Andreas <andreas.zeugswetter@telecom.at>; meskes@topsystem.de; pgsql-hackers@hub.org
Jan Wieck wrote:
>
> Andreas wrote:
> >
> > 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 ?
>
> BEGIN/END in PL/SQL and PL/pgSQL doesn't mean transactions!
> It's just to group statements to a block. You cannot commit
> something inside a PostgreSQL function. All changes made by a
> function are covered by the statements transaction or the
> upper transaction block.
This will be changed - there is a way to implement nested transaction!
And so, some day we will need in something to start/end transaction
block inside functions.
Vadim
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: AW: [HACKERS] Begin statement again
1970-01-01 00:00 AW: [HACKERS] Begin statement again Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
1998-03-13 12:43 ` Re: AW: [HACKERS] Begin statement again Jan Wieck <jwieck@debis.com>
1998-03-25 03:43 ` Re: AW: [HACKERS] Begin statement again Vadim B. Mikheev <vadim@sable.krasnoyarsk.su>
@ 1998-03-25 06:16 ` David Gould <dg@illustra.com>
1 sibling, 0 replies; 14+ messages in thread
From: dg@illustra.com @ 1998-03-25 06:16 UTC (permalink / raw)
To: vadim@sable.krasnoyarsk.su; +Cc: jwieck@debis.com; andreas.zeugswetter@telecom.at; meskes@topsystem.de; pgsql-hackers@hub.org
Andreas wrote:
>
> 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 ?
Because without transactions it is darn near impossible to build a database
that can guarantee data consistancy. Transactions are _the_ tool used to
build robust systems that remain usable even after failures.
For example take the simple single statment:
insert into customers values("my name", customer_number("my name"));
Assuming that there is an index on the name and id # columns, what happens
if the system dies after the name index is updated, but the id # index
is not? Your indexes are corrupt. With transactions, the whole thing just
rolls back and remains consistant.
Since PostgreSQL is more powerful than many databases, it is just about
impossible for a client application to tell what is really happening and
whether a transaction is needed even if the client only is using very
simple SQL that looks like it doesn't need a transaction.
Take the SQL statement above and add a trigger or rule on the customers
table like so:
create rule new_cust on insert to customers do after
insert into daily_log values ("new customer", new.name);
update statistics set total_customers = total_customers + 1 ...
Now you really need a transaction.
Oh, but lets look at the customer_number() function:
begin
return (select unique max(cust_no) + 1 from customers);
end
This needs to lock the whole table and cannot release those locks until
the insert to customer is done. This too must be part of the transaction.
Fortunately, unlike say 'mySQL', posgreSQL does the right thing and always
has a transaction wrapped around any statement.
-dg
David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
- Linux. Not because it is free. Because it is better.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: AW: [HACKERS] Begin statement again
1970-01-01 00:00 AW: [HACKERS] Begin statement again Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
1998-03-13 12:43 ` Re: AW: [HACKERS] Begin statement again Jan Wieck <jwieck@debis.com>
1998-03-25 03:43 ` Re: AW: [HACKERS] Begin statement again Vadim B. Mikheev <vadim@sable.krasnoyarsk.su>
@ 1998-03-25 09:36 ` Jan Wieck <jwieck@debis.com>
1 sibling, 0 replies; 14+ messages in thread
From: jwieck@debis.com @ 1998-03-25 09:36 UTC (permalink / raw)
To: vadim@sable.krasnoyarsk.su; +Cc: pgsql-hackers
Vadim wrote:
>
> Jan Wieck wrote:
> >
> > Andreas wrote:
> > >
> > > 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 ?
> >
> > BEGIN/END in PL/SQL and PL/pgSQL doesn't mean transactions!
> > It's just to group statements to a block. You cannot commit
> > something inside a PostgreSQL function. All changes made by a
> > function are covered by the statements transaction or the
> > upper transaction block.
>
> This will be changed - there is a way to implement nested transaction!
> And so, some day we will need in something to start/end transaction
> block inside functions.
What exactly is planned for this?
Will it be possible to begin/commit a subtransaction so that
updates done before and after it could still get rolled back
while things inside remain persistent?
Or would it be possible to commit up to now and resume (maybe
a new transaction)?
What would the syntax be for these statements, or must the
function/trigger call special functions in the backend on the
C level?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
^ permalink raw reply [nested|flat] 14+ messages in thread
* AW: [HACKERS] Begin statement again
@ 1970-01-01 00:00 Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
1998-03-20 12:57 ` Re: AW: [HACKERS] Begin statement again Michael Meskes <meskes@topsystem.de>
0 siblings, 1 reply; 14+ messages in thread
From: Zeugswetter Andreas @ 1970-01-01 00:00 UTC (permalink / raw)
To: 'Meskes, Michael' <meskes@topsystem.de>; +Cc: 'pgsql-hackers@hub.org' <pgsql-hackers@hub.org>
Oracle, like DB/2 can' t set it to on. The autocommit ***on*** in ORA ODBC is a trick.
It simply silently adds commit once in a while (after every statement).
But please to make the vokabulary easy don't refer to begin, but to 'begin work'
in this context. 'begin' will mean begin a statement block, not a transaction block.
Andreas
> How do you set autocommit off in ORACLE embedded SQL? I only know this
> from ODBC.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: AW: [HACKERS] Begin statement again
1970-01-01 00:00 AW: [HACKERS] Begin statement again Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
@ 1998-03-20 12:57 ` Michael Meskes <meskes@topsystem.de>
0 siblings, 0 replies; 14+ messages in thread
From: Michael Meskes @ 1998-03-20 12:57 UTC (permalink / raw)
To: andreas.zeugswetter@telecom.at; +Cc: pgsql-hackers
Zeugswetter Andreas writes:
> Oracle, like DB/2 can' t set it to on. The autocommit ***on*** in ORA ODBC is a trick.
> It simply silently adds commit once in a while (after every statement).
I know. The problem we were talking about was the automatic beginning of a
transaction. No need to say "begin work" it just starts.
> But please to make the vokabulary easy don't refer to begin, but to 'begin work'
> in this context. 'begin' will mean begin a statement block, not a transaction block.
I know that, too. But currently in postgresql begin means the same as begin
work. Correct me if I'm wrong.
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
^ permalink raw reply [nested|flat] 14+ messages in thread
* AW: [HACKERS] Begin statement again
@ 1970-01-01 00:00 Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
1998-03-25 15:57 ` Re: AW: [HACKERS] Begin statement again Michael Meskes <meskes@topsystem.de>
1998-03-25 16:33 ` Re: AW: [HACKERS] Begin statement again Jan Wieck <jwieck@debis.com>
0 siblings, 2 replies; 14+ messages in thread
From: Zeugswetter Andreas @ 1970-01-01 00:00 UTC (permalink / raw)
To: 'Michael Meskes' <meskes@topsystem.de>; +Cc: 'pgsql-hackers@hub.org' <pgsql-hackers@hub.org>
>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
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: AW: [HACKERS] Begin statement again
1970-01-01 00:00 AW: [HACKERS] Begin statement again Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
@ 1998-03-25 15:57 ` Michael Meskes <meskes@topsystem.de>
1998-03-26 14:10 ` Re: AW: [HACKERS] Begin statement again Jose' Soares Da Silva <sferac@proxy.bazzanese.com>
1 sibling, 1 reply; 14+ messages in thread
From: Michael Meskes @ 1998-03-25 15:57 UTC (permalink / raw)
To: andreas.zeugswetter@telecom.at; +Cc: pgsql-hackers
Zeugswetter Andreas writes:
> 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.
You got a point with this.
> Hmmm ? you don't tell the backend when the program exits ?
So far I don't. Does anyone know whether there's a disconnect command
somewhere? In embedded SQL that is. Oracle uses 'commit work release'.
The function I have to call does exist already.
> 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.
I do not hide it all. But I'd like to be as compatible to Oracle as
possible. Maybe we could add an autotransaction flag somehow.
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
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: AW: [HACKERS] Begin statement again
1970-01-01 00:00 AW: [HACKERS] Begin statement again Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
1998-03-25 15:57 ` Re: AW: [HACKERS] Begin statement again Michael Meskes <meskes@topsystem.de>
@ 1998-03-26 14:10 ` Jose' Soares Da Silva <sferac@proxy.bazzanese.com>
0 siblings, 0 replies; 14+ messages in thread
From: Jose' Soares Da Silva @ 1998-03-26 14:10 UTC (permalink / raw)
To: Michael Meskes <meskes@topsystem.de>; +Cc: Zeugswetter Andreas <andreas.zeugswetter@telecom.at>; pgsql-hackers
On Wed, 25 Mar 1998, Michael Meskes wrote:
> Zeugswetter Andreas writes:
> > 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.
>
> You got a point with this.
>
> > Hmmm ? you don't tell the backend when the program exits ?
>
> So far I don't. Does anyone know whether there's a disconnect command
> somewhere? In embedded SQL that is. Oracle uses 'commit work release'.
>
The DISCONNECT statement is used to terminate an inactive
SQL-Connection. A SQL-Connection can be closed whether it is the
current SQL-Connection or a dormant SQL-Connection, but may not
closed while a transaction is on-going for its associated
SQL-session.
The required syntax for the DISCONNECT statement is:
DISCONNECT
<Connection Name> |
DEFAULT |
CURRENT |
ALL
Ciao, Jose'
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: AW: [HACKERS] Begin statement again
1970-01-01 00:00 AW: [HACKERS] Begin statement again Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
@ 1998-03-25 16:33 ` Jan Wieck <jwieck@debis.com>
1998-03-26 08:12 ` Re: AW: [HACKERS] Begin statement again Michael Meskes <meskes@topsystem.de>
1 sibling, 1 reply; 14+ messages in thread
From: jwieck@debis.com @ 1998-03-25 16:33 UTC (permalink / raw)
To: andreas.zeugswetter@telecom.at; +Cc: meskes@topsystem.de; pgsql-hackers@hub.org
Andreas wrote:
>
>
> >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.
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?
In oratcl autocommit is ON by default and I assumed this is
the libraries default too. Correct me if I'm wrong.
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
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
open locks laying around since ecpg doesn't send 'BEGIN
TRANSACTION' and PostgreSQL's default is somewhat like
autocommit too.
>
> >>
> >>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 ?
Isn't EOF information enough? Must a client say BYE?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: AW: [HACKERS] Begin statement again
1970-01-01 00:00 AW: [HACKERS] Begin statement again Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
1998-03-25 16:33 ` Re: AW: [HACKERS] Begin statement again Jan Wieck <jwieck@debis.com>
@ 1998-03-26 08:12 ` Michael Meskes <meskes@topsystem.de>
0 siblings, 0 replies; 14+ messages in thread
From: Michael Meskes @ 1998-03-26 08:12 UTC (permalink / raw)
To: jwieck@debis.com; +Cc: 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
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: AW: [HACKERS] Begin statement again
@ 1998-03-13 17:28 sferac@bo.nettuno.it
0 siblings, 0 replies; 14+ messages in thread
From: sferac@bo.nettuno.it @ 1998-03-13 17:28 UTC (permalink / raw)
To: Zeugswetter Andreas <andreas.zeugswetter@telecom.at>; +Cc: 'Michael Meskes' <meskes@topsystem.de>; 'pgsql-hackers@hub.org' <pgsql-hackers@hub.org>
On Fri, 13 Mar 1998, Zeugswetter Andreas wrote:
> 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)
Apologies for intrusion.
I think we don't need BEGIN/END at all, these statements aren't SQL standard.
END is an alias for COMMIT.
(why do we need two statements to do the same thing?).
from man commit:
"...
This commands commits the current transaction. All
changes made by the transaction become visible to others
and are guaranteed to be durable if a crash occurs.
COMMIT is functionally equivalent to the END command"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
from man begin:
"...
commands commits the current transaction. All
changes made by the transaction become visible to others
and are guaranteed to be durable if a crash occurs."
and BEGIN should be changed to SQL standard SET TRANSACTION statement.
-------
PS:
I think PL/pgSQL is an eccellent idea. Go for it.
Ciao, Jose'
^ permalink raw reply [nested|flat] 14+ messages in thread
* RE: AW: [HACKERS] Begin statement again
@ 1998-03-14 18:20 Meskes, Michael <meskes@topsystem.de>
0 siblings, 0 replies; 14+ messages in thread
From: Meskes, Michael @ 1998-03-14 18:20 UTC (permalink / raw)
To: Zeugswetter Andreas <andreas.zeugswetter@telecom.at>; sferac@bo.nettuno.it; +Cc: 'Michael Meskes' <meskes@topsystem.de>; 'pgsql-hackers@hub.org' <pgsql-hackers@hub.org>
We, that is ecpg, will need BEGIN and END to include blocks of Pl/pgSQL.
I think this can be modelled after ORACLE's PL/SQL. in your embedded SQL
code you say:
...
exec sql begin;
<some PL/SQL code, for instance the call of a stored
procedure>
exec sql end;
...
And I'd really like to call a stored procedure from my C program.
Michael
--
Dr. Michael Meskes, Projekt-Manager | topystem Systemhaus GmbH
meskes@topsystem.de | Europark A2, Adenauerstr. 20
meskes@debian.org | 52146 Wuerselen
Go SF49ers! Use Debian GNU/Linux! | Tel: (+49) 2405/4670-44
> ----------
> From: sferac@bo.nettuno.it[SMTP:sferac@bo.nettuno.it]
> Sent: Freitag, 13. März 1998 18:28
> To: Zeugswetter Andreas
> Cc: 'Michael Meskes'; 'pgsql-hackers@hub.org'
> Subject: Re: AW: [HACKERS] Begin statement again
>
> On Fri, 13 Mar 1998, Zeugswetter Andreas wrote:
>
> > 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)
>
> Apologies for intrusion.
>
> I think we don't need BEGIN/END at all, these statements aren't SQL
> standard.
> END is an alias for COMMIT.
> (why do we need two statements to do the same thing?).
>
> from man commit:
> "...
> This commands commits the current transaction. All
> changes made by the transaction become visible to others
> and are guaranteed to be durable if a crash occurs.
> COMMIT is functionally equivalent to the END command"
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> from man begin:
> "...
> commands commits the current transaction. All
> changes made by the transaction become visible to others
> and are guaranteed to be durable if a crash occurs."
>
> and BEGIN should be changed to SQL standard SET TRANSACTION statement.
> -------
> PS:
> I think PL/pgSQL is an eccellent idea. Go for it.
> Ciao,
> Jose'
>
>
^ permalink raw reply [nested|flat] 14+ messages in thread
end of thread, other threads:[~1998-03-26 14:10 UTC | newest]
Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1970-01-01 00:00 AW: [HACKERS] Begin statement again Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
1998-03-13 12:43 ` Jan Wieck <jwieck@debis.com>
1998-03-25 03:43 ` Vadim B. Mikheev <vadim@sable.krasnoyarsk.su>
1998-03-25 06:16 ` David Gould <dg@illustra.com>
1998-03-25 09:36 ` Jan Wieck <jwieck@debis.com>
1970-01-01 00:00 AW: [HACKERS] Begin statement again Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
1998-03-20 12:57 ` Michael Meskes <meskes@topsystem.de>
1970-01-01 00:00 AW: [HACKERS] Begin statement again Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
1998-03-25 15:57 ` Michael Meskes <meskes@topsystem.de>
1998-03-26 14:10 ` Jose' Soares Da Silva <sferac@proxy.bazzanese.com>
1998-03-25 16:33 ` Jan Wieck <jwieck@debis.com>
1998-03-26 08:12 ` Michael Meskes <meskes@topsystem.de>
1998-03-13 17:28 Re: AW: [HACKERS] Begin statement again sferac@bo.nettuno.it
1998-03-14 18:20 RE: AW: [HACKERS] Begin statement again Meskes, Michael <meskes@topsystem.de>
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