It looks like transaction, but it isn't transaction

From: Sergey Samokhin <prikrutil(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: It looks like transaction, but it isn't transaction
Date: 2009-08-26 01:06:27
Message-ID: e42595410908251806w1eefb874p17d050603af8fa0b@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello.

PostgreSQL driver I'm using let me execute queries made by combining
some commands into one statement:

pgsql:squery(Conn, "CREATE TABLE foo (id int); INSERT INTO foo VALUES
(1), (2)");

There is one thing I find especially interesting: queries I pass to
the pgsql:squery() are executed with some properties specific to
transactions!

For example the following query will be rejected, because bar table
doesn't exist:

pgsql:squery(Conn, "DELETE FROM foo; SELECT * FROM bar") % DELETE
command won't actually delete rows from foo because there is no bar
table

First I thought that my driver just encloses queries I pass in
BEGIN/COMMIT, but I haven't found any of those keywords in the
sources. And SAVEPOINT's also don't work inside this "transactions" as
it would be if driver used BEGIN/COMMIT to make a query into
transaction.

Then I made a decision that this is some kind of convention on how
complex queries delivered from drivers are executed by PostgreSQL.

I'm going to rely on this behaviour as "transactions without
SAVEPOINT/ROLLBACK TO" in some cases but I'm a bit afraid of troubles
that may appear in the future.

Is this behavior explained somewhere in documentation in more detail?
How does this behaviour differ from the traditional transactions which
are defined by enclosing SQL commands in BEGIN/COMMIT?

Thanks.

--
Sergey Samokhin

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Sam Mason 2009-08-26 01:20:25 Re: cluster replication over only http protocol
Previous Message Scott Marlowe 2009-08-26 00:21:20 Re: cluster replication over only http protocol