On 10/06/2016 09:09 AM, Geoff Winkless wrote:
> 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.
I do not see sarcasm, I see someone trying to work through what is a
complex scenario.
>
> _As far as the transaction is concerned_, after the command the table
What command?
> 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.
What function?
Part of the problem with trying to sort out what you want is working off
only snippets of code at a time.
So is it possible to show a complete example of what you are doing?
>
>> 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
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com