Re: Add regression tests for autocommit-off mode for psql and fix some omissions

From: Marko Tiikkaja <marko(at)joh(dot)to>
To: Feike Steenbergen <feikesteenbergen(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add regression tests for autocommit-off mode for psql and fix some omissions
Date: 2014-10-07 07:55:09
Message-ID: 54339C5D.2070802@joh.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/7/14, 9:11 AM, Feike Steenbergen wrote:
> Perhaps I am the only one using autocommit-off mode

You most definitely aren't.

> and we shouldn't put effort
> into fixing this?

It's not clear to me that this is fixing a problem, to be honest. If
you're running autocommit=off, you have an expectation that you can roll
back commands at will. It's fine if I can't roll back a VACUUM, for
example, since I would practically never want to do that. But ALTER
TYPE .. ADD VALUE ..; is an entirely different beast. That one's
permanent; there's no DROP equivalent. If the command is just executed,
and I can't roll it back, wouldn't that be a serious violation of the
principle of least astonishment? DROP INDEX CONCURRENTLY has a bit of
the same problem. You can CREATE INDEX CONCURRENTLY, but it might take
days in some cases.

I think that just running the command is a bad idea, and if we want to
fix something here we should focus on just providing a better error message.

.marko

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2014-10-07 09:42:39 Re: Feasibility of supporting bind params for all command types
Previous Message Feike Steenbergen 2014-10-07 07:11:13 Re: Add regression tests for autocommit-off mode for psql and fix some omissions