Andrew Dunstan <andrew@dunslane.net> 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