It looks like transaction, but it isn't transaction - Mailing list pgsql-general

From Sergey Samokhin
Subject It looks like transaction, but it isn't transaction
Date
Msg-id e42595410908251806w1eefb874p17d050603af8fa0b@mail.gmail.com
Whole thread Raw
Responses Re: It looks like transaction, but it isn't transaction
List 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

pgsql-general by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: cluster replication over only http protocol
Next
From: Sam Mason
Date:
Subject: Re: cluster replication over only http protocol