On 6 October 2016 at 16:57, Francisco Olarte <folarte@peoplecall.com> wrote:
> You are contradicting yourself. First you say after the command it
> must not exist. Then you say to do it at commit time. If it is done at
> commit time you cannot guarantee it does not exist after the command.
I'm not contradicting myself at all, and frankly I'd rather this
argument didn't degenerate into the level of playground sarcasm that
you seem to be employing.
_As far as the transaction is concerned_, after the command the table
should not exist. The rest of the system should not give two hoots
about what happens inside my transaction until after COMMIT. This is
how I can DROP a table, then roll it back and magically that table
still exists; it's how I can insert values into a table and roll back,
and those values aren't in the table; it's how I can delete rows from
a table, roll back and those values "magically" (as you put it) still
exist. So the DROP is done at COMMIT time, as far as everyone else is
concerned, but immediately as far as the transaction is concerned.
> And using the branch for testing is not logically bankrupt, atomic
> operations with responses are there for a second, this is why
> processors have 'test and set' and 'compare-exchange' and similar.
But that's NOT what this function is for. It's designed to remove a
table without producing an error if it didn't exist. The fact that its
RETURN value is "DROP TABLE", whether it dropped or not, shows this.
> And the notice is not the reason it is not done
> at commit time, the reason is the one you said, action must be taken
> when you issue the command, not a magic convenient time in the future
I've no idea what this paragraph means.
Geoff