Andrew Dunstan <[EMAIL PROTECTED]> writes: > Alvaro Herrera wrote: >> Also, DIE does not need to lock the table afterwards because it won't >> exist, but CINE needs to keep a lock until transaction commit.
> Right. That's one reason I thought of starting with the DIE case ;-) That argument seems pretty wrongheaded to me --- if there was a table and DIE dropped it, you *will* be holding a lock until commit. DROP can be rolled back, remember? CINE will need to keep a lock too, at least in the cases where it creates or modifies the table, though you could possibly choose to drop the lock immediately if there's no change. I don't see any real use for CINE --- it's too nonintuitive about what will happen. Does it adjust the table definition to match if different? Does it truncate away the data inside the table (it certainly must if it changes the table definition)? If so, what about foreign keys? The implication of that command name is that nothing happens if the table exists, regardless of definition or contents. Which seems a pretty useless behavior. We know that DIE is a convenient, useful semantics because people keep asking for it. I think CINE has no track record. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings