From: | "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Christopher Browne <cbbrowne(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: psql - -dry-run option |
Date: | 2015-12-18 08:50:20 |
Message-ID: | CACACo5T22od55X1cVaGkfN5hwPtULCnLK3QojFx0Fd_ZQ0SYMA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 17, 2015 at 9:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Whether we really need a feature like that isn't clear though; it's not
> like it's hard to test things that way now. Stick in a BEGIN with no
> COMMIT, you're there. The problem only comes in if you start expecting
> the behavior to be bulletproof. Maybe I'm being too pessimistic about
> what people would believe a --dry-run switch to be good for ... but
> I doubt it.
>
I'm on the same line: BEGIN/ROLLBACK requires trivial effort and a
--dry-run option might give a false sense of security, but it cannot
possibly rollback side-effects of user functions which modify filesystem or
interact with the outside world in some other way.
--
Alex
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2015-12-18 08:54:14 | Re: parallel joins, and better parallel explain |
Previous Message | Amit Kapila | 2015-12-18 08:49:23 | Re: Patch: fix lock contention for HASHHDR.mutex |