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
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 |