* Tom Lane (t...@sss.pgh.pa.us) wrote: > Second, to my mind the point of a multi-table TRUNCATE is to ensure that > all the referenced tables get reset to empty *together*. With something > like this, you'd have no such guarantee. Consider a timeline like this:
Don't we have the exact same issue with DROP TABLE and multi-table
support for it today..?
Session 1 Session 2
DROP IF EXISTS a, b, c;
... finds c doesn't exist ...
... working on a and b ...
CREATE TABLE c ( ... );
... commits ...
But now we have a table 'c' where we didn't expect to because we DROP'd
it? If you COMMIT then you can't expect things to not have changed under
you after your transaction is over, you're going to have to be ready to
deal with the consequences either way..
Heck, even if your scenario, don't you have to be concerned in Session 1
that someone insert'd data into 'c' after your commit but before you
open your next transaction?
The TRUNCATE in a multi-table case, imv, is typically to address FK
relationships. Provided we don't allow a situation where data could be
stored which violates a FK due to a TRUNCATE IF EXISTS happening in some
other session concurrently (which I don't think could happen, but it'd
be something to verify, I suppose), the precedent of proceeding with
multi-table IF EXISTS commands even in the face of a given table not
existing should hold.
If we don't feel that is appropriate for TRUNCATE, then I would question
if we should have it for DROP TABLE- but if we don't have that semantic,
what are we going to have? All tables have to either exist or not
exist? Disallow IF EXISTS when a multi-table command is given? Neither
strikes me as better.
Thanks,
Stephen
signature.asc
Description: Digital signature
