On 6 October 2016 at 16:57, Francisco Olarte <folarte@xxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
