To: Ron Johnson <ron.l.johnson@cox.net>
cc: pgsql general <pgsql-general@postgresql.org>
Subject: Re: Notes on converting from MySQL 5.0.x to PostgreSQL 
In-reply-to: <44A5418F.8040901@cox.net> 
References: <b0f0a0e00606300617j2ed6dd4cub7bc2db972f6211a@mail.gmail.com>
	<1151680333.13129.55.camel@state.g2switchworks.com>
	<44A5418F.8040901@cox.net>
Comments: In-reply-to Ron Johnson <ron.l.johnson@cox.net>
	message dated "Fri, 30 Jun 2006 10:21:51 -0500"
Date: Fri, 30 Jun 2006 11:50:47 -0400
Message-ID: <24462.1151682647@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Ron Johnson <ron.l.johnson@cox.net> writes:
> Scott Marlowe wrote:
>> However, the more interesting thing here, is that every
>> statement, including DDL is transactable, except for a couple of
>> big odd ones, like create database. So, in postgresql, you can do:

> But isn't that what it means to be "transactional"?  Or am I spoiled
>  by my "big, expensive enterprise database"?

Being able to roll back DDL (table-schema modifications) isn't that
common.  Since PG keeps most of its schema information in tables,
we have it easier than some other systems supporting DDL rollback,
but it's still tricky.  As an example, a long time ago we used to
name table files after the table and database directories after the
database, which made it easy to see what was what under $PGDATA,
but prevented a lot of DDL from being transactional.  For instance

	BEGIN;
	DROP TABLE foo;
	CREATE TABLE foo (some-new-definition);
	ROLLBACK;

couldn't work because there would need to be two physical files named
foo in the interim until you commit or roll back.  ALTER TABLE RENAME
had some related problems.  Now we name all the filesystem objects using
OIDs that can be chosen to never collide, even if they belong to
database objects with similar names.

Last I checked, mysql was still using table names for file names,
so they're on the wrong side of this.

			regards, tom lane