In response to Tom Lane <[EMAIL PROTECTED]>: > "Bill Moran" <[EMAIL PROTECTED]> writes: > > Issuing a statement like: > > CREATE TABLE table2 AS SELECT * FROM table1; > > simultaneously in two separate sessions should result in an error like > > "ERROR: relation "table2" already exists" (in one or the other of the > > sessions, depending on the exact timing of things). > > This isn't really fixable, or at least the cure would be worse than the > disease. The "already exists" message is just a pre-check and it cannot > detect an uncommitted concurrent attempt to insert the same table name. > The place where the rubber really meets the road is during unique index > insertion. We might be able to fix things so that you get a unique > index complaint about pg_class.relname instead of pg_type, but that > would be about it.
I figured it was something along those lines, otherwise it would have already been "fixed". I haven't had time to look at the code, so I'm speaking from a position of ignorance, but would it be terribly difficult to catch the unique constraint error, then re-run the pre-check to determine if it's occurring as a result of trying to create an existing table, and translate the error to a friendlier one before reporting to the client? That doesn't seem unreasonable to me, but (as I already admitted) I haven't looked at the code yet ... -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
