Robert Haas <robertmh...@gmail.com> writes: > On Tue, Oct 9, 2012 at 4:18 PM, Josh Berkus <j...@agliodbs.com> wrote: >> The second is for making deployment scripts idempotent. For example, >> say you have script A which creates table "josh", and script B which >> needs table "josh" to be empty, if present. Since the two scripts are >> tied to different database features, and you don't know which one will >> be deployed first, it's useful to have TRUNCATE IF EXISTS. Yes, you can >> solve that problem with DO, but why make users go to the extra effort?
> Hmm. That's an interesting point. I'm still not buying this as a realistic use-case. The only way TRUNCATE IF EXISTS helps script B is if B isn't going to do *anything* with table "josh" except truncate it. I will grant that there might be a case or two out there where that's just the ticket, but I think they're probably few and far between; not enough to justify bespoke syntax. As Robert already pointed out, a quick DO handles the problem well enough if you only need it once in a blue moon. I also note the lack of response to my point about IF EXISTS being squishy to the point of outright dangerous in the multi-table case. I might hold still and not complain if we didn't have the multi-table syntax. But with it, this looks a lot less like a well-considered feature and a lot more like something that was implemented because it could be done in two lines, as long as you aren't too picky about what the semantics are. TBH, I think most all of our ventures in IF(NOT)EXISTS have suffered from that disease, but that doesn't mean I'm not going to complain when we adopt the same cowboy approach to command semantics for ever thinner justifications. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers