Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-general

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

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

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

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?


Sergey Samokhin


pgsql-general by date

Next:From: Sam MasonDate: 2009-08-26 01:20:25
Subject: Re: cluster replication over only http protocol
Previous:From: Scott MarloweDate: 2009-08-26 00:21:20
Subject: Re: cluster replication over only http protocol

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group