On 10/09/2012 04:06 PM, Tom Lane 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: > > Session 1 Session 2 > > TRUNCATE IF EXISTS a, b, c; > ... finds c doesn't exist ... > ... working on a and b ... > CREATE TABLE c ( ... ); > INSERT INTO c ...; > ... commits ... > > Now we have a, b, and c, but c isn't empty, violating the expectations > of session 1. So even if there's a use-case for IF EXISTS on a single > table, I think it's very very dubious to allow it in multi-table > commands.
Hi, I've to say that I don't understand your timeline : - If c exist in Session 1, CREATE TABLE in Session 2 can't be done, neither INSERT - If c doesn't exists in Session 1, it will be ignored, then, Session 2 work fine. In any case, TRUNCATE is sent before INSERT, but it can't lock an object which still not exists. I understand that people don't want TRUNCATE IF EXISTS, but, in my point of view, even if TRUNCATE is not a DDL, it's the same use-case as DROP TABLE IF EXISTS. Regards, -- Sébastien Lardière PostgreSQL DBA Team Manager Hi-Media -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
