Re: psql - -dry-run option

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql - -dry-run option
Date: 2015-12-17 19:14:09
Message-ID: CAFj8pRCRGsKuz3Uu+BW0dPTCSsad799bRiMymYjMZmrZg2oUhA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2015-12-17 20:03 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > when I read a blog
> >
> http://www.depesz.com/2015/12/14/waiting-for-9-6-psql-support-multiple-c-and-f-options-and-allow-mixing-them/
> > where is emulated dry-run mode, I though so we can implement it very
> > simply.
>
> Not one that is actually reliable. All a script would have to do is
> include its own begin/commit commands, and it would override what you
> are talking about. It's okay, in my opinion, if the -1 switch is just a
> half-baked "best effort" solution. It's not okay to provide a --dry-run
> switch that is equally full of holes, because if someone were to actually
> rely on it to not execute the script, the possibility of an override would
> amount to a security bug.
>

My idea was enforce global transaction (-1) option and ensure STOP_ON_ERROR
mode (cannot be changed later). Any inner COMMIT or ROLLBACK have to be
disallowed (or ignored) - what can be problem :(

and if all statements from input stream was processed, then ROLLBACK is
emitted, but result is success.

Pavel

>
> regards, tom lane
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-12-17 19:16:27 Re: psql - -dry-run option
Previous Message Tom Lane 2015-12-17 19:03:55 Re: psql - -dry-run option