Re: \set AUTOROLLBACK ON

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: Joel Jacobson <joel(at)trustly(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Lukas Gratte <lukas(at)trustly(dot)com>
Subject: Re: \set AUTOROLLBACK ON
Date: 2017-06-26 19:35:47
Message-ID: CAKFQuwaZzX0sH4ViOTx_KjxqK0G2OW3GMug-XdyGjhLXkScd-Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 26, 2017 at 12:19 PM, David Fetter <david(at)fetter(dot)org> wrote:

> On Mon, Jun 26, 2017 at 04:00:55PM +0200, Joel Jacobson wrote:
> > Hi hackers,
> >
> > A colleague of mine wondered if there is a way to always run
> > everything you type into psql in a db txn and automatically rollback
> > it as soon as it finish.
> > I couldn't think of any way to do so, but thought it would be a nice
> > feature and probably quite easy to add to psql, so I thought I should
> > suggest it here.
> >
> > The typical use-case is you are doing something in production that you
> > just want to
> > a) test if some query works like expected and then rollback
> > or,
> > b) read-only queries that should not commit any changes anyway, so
> > here the rollback would just be an extra layer of security, since your
> > SELECT might call volatile functions that are actually not read-only
> >
> > Thoughts?
>
> Multi-statement transactions:
>
> Would flavor of BEGIN TRANSACTION undo the feature?
> If not, would it auto-munge COMMIT into a ROLLBACK?
>

​We already have SET TRANSACTION READ ONLY.

If you begin a transaction and do not issue an explicit commit when the
session closes the default action is ROLLBACK.

At some point if you want to use SQL features you need to write SQL - not
pass command-line arguments to the client.

See also ".psqlrc" and shell functions/aliases.

This doesn't seem like material to build into psql but since the proposal
lacks an envisioned usage its hard to say conclusively. Interplay with the
various ways to source SQL, and existing arguments, is a prime area of
concern.

Side effects:
>
> Let's imagine you have a function called
> ddos_the_entire_internet(message TEXT), or something less drastic
> which nevertheless has side effects the DB can't control.
>
> How should this mode handle it? Should it try to detect calls to
> volatile functions, or should it just silently fail to do what
> it's promised to do?
>

​It doesn't need to promise anything more than what happens today if
someone manually keys in

BEGIN;
[...]
ROLLBACK;

​using psql prompts.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2017-06-26 19:55:35 Re: Pluggable storage
Previous Message David Fetter 2017-06-26 19:19:15 Re: \set AUTOROLLBACK ON