From: | Cédric Villemain <cedric(at)2ndquadrant(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Sébastien Lardière <slardiere(at)hi-media(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Truncate if exists |
Date: | 2012-10-09 14:50:58 |
Message-ID: | 201210091650.59290.cedric@2ndquadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> For starters, the use-case hasn't been explained to my satisfaction.
> In what situation is it actually helpful to TRUNCATE a table that's
> not there yet? Aren't you going to have to do a CREATE IF NOT EXISTS
> to keep from failing later in the script? If so, why not just do that
> first?
There is a use case for the truncate 'mutliple' tables, maybe less clear for a single table.
Sébastien will speak here I suppose.
> 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.
well, in such case you probably don't want to use IF EXISTS.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2012-10-09 15:39:24 | Re: Add FET to Default and Europe.txt |
Previous Message | Vik Reykja | 2012-10-09 14:44:07 | Re: DEALLOCATE IF EXISTS |