On Mon, Jun 26, 2017 at 12:19 PM, David Fetter <david@fetter.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