What I just committed uses your idea of auto-committing TRUNCATE et al,
but now that I review the thread I think that everyone else thought that
that was a dangerous idea. How do you feel about simply throwing an error
in autocommit-off mode, instead? (At least it's a localized
change
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I just noticed that this afternoon's changes cause dblink's regression
test to fail due to:
CREATE OR REPLACE FUNCTION conditional_drop()
[...]
IF FOUND THEN
DROP DATABASE regression_slave;
END IF;
[...]
'
Tom Lane wrote:
We can go with the auto-COMMIT idea for statements that are invoked at
the outer interactive level, but that doesn't work for stuff invoked
inside a function. I think we need to forbid these statements inside
functions, too. We already have that for VACUUM, because of its
Joe Conway [EMAIL PROTECTED] writes:
I just noticed that this afternoon's changes cause dblink's regression
test to fail due to:
CREATE OR REPLACE FUNCTION conditional_drop()
[...]
IF FOUND THEN
DROP DATABASE regression_slave;
END IF;
[...]
' LANGUAGE 'plpgsql';
Tom Lane wrote:
In the meantime, to tell you the truth, the cleanest way to handle the
dblink regression test would be to make it circularly connect to
database regression. I know this seems cheesy, but as long as the
software under test doesn't know that it's a connection-to-self, seems
like
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
There are a number of statements, such as TRUNCATE TABLE, that refuse to
run in a transaction block because they perform actions that can't be
rolled back later.
These statements currently do not look at
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
There are a number of statements, such as TRUNCATE TABLE, that refuse to
run in a transaction block because they perform actions that can't be
rolled back later.
These statements currently do not look at autocommit, which means that
... I think we
should just do an automatic COMMIT if it is the first statement of a
transaction, and if not, throw the same error we used to throw. We are
performing autocommit for SET at the start of a transaction now anyway,
so it isn't totally strange to do it for TRUNCATE, etc. too.
Tom Lane wrote:
... I think we
should just do an automatic COMMIT if it is the first statement of a
transaction, and if not, throw the same error we used to throw. We are
performing autocommit for SET at the start of a transaction now anyway,
so it isn't totally strange to do it for
Bruce Momjian [EMAIL PROTECTED] writes:
Maybe we can throw a WARNING when autocommit is on. Would that make
everyone happy?
I doubt it, because by the time you read the WARNING it's too late:
the statement's already committed.
regards, tom lane
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Maybe we can throw a WARNING when autocommit is on. Would that make
everyone happy?
I doubt it, because by the time you read the WARNING it's too late:
the statement's already committed.
I assume the same limitation would hold for
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Maybe we can throw a WARNING when autocommit is on. Would that make
everyone happy?
I doubt it, because by the time you read the WARNING it's too late:
the statement's already committed.
I
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Maybe we can throw a WARNING when autocommit is on. Would that make
everyone happy?
I doubt it, because by the time you read the WARNING it's too late:
the statement's
Bruce Momjian [EMAIL PROTECTED] writes:
One particularly nasty problem is issuing a VACUUM or TRUNCATE in cases
where you don't know the autocommit mode. You could set autocommit to
'on', and issue the command, but how do you know if you need to turn
autocommit back off again?
Perhaps RESET
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
One particularly nasty problem is issuing a VACUUM or TRUNCATE in cases
where you don't know the autocommit mode. You could set autocommit to
'on', and issue the command, but how do you know if you need to turn
autocommit back off
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Perhaps RESET AUTOCOMMIT is a good enough answer?
I was unclear on that. RESET sets it back to the postgresql.conf value,
right? Do we know that the session didn't change it earlier in the
script? That's where it gets tricky.
You're
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Perhaps RESET AUTOCOMMIT is a good enough answer?
I was unclear on that. RESET sets it back to the postgresql.conf value,
right? Do we know that the session didn't change it earlier in the
script? That's where
On Fri, 18 Oct 2002, Mike Mascari wrote:
Gavin Sherry wrote:
On Fri, 18 Oct 2002, Tom Lane wrote:
Anyone see a way out of this catch-22? If not, which is the least
bad alternative?
Ultimately, fix TRUNCATE to be transaction safe. This is non-trivial,
I know :-).
There are a number of statements, such as TRUNCATE TABLE, that refuse to
run in a transaction block because they perform actions that can't be
rolled back later.
These statements currently do not look at autocommit, which means that
if autocommit is off, their tests will succeed ... but then a
Tom Lane wrote:
There are a number of statements, such as TRUNCATE TABLE, that refuse to
run in a transaction block because they perform actions that can't be
rolled back later.
These statements currently do not look at autocommit, which means that
if autocommit is off, their tests will succeed
On Fri, 18 Oct 2002, Tom Lane wrote:
Anyone see a way out of this catch-22? If not, which is the least
bad alternative?
Ultimately, fix TRUNCATE to be transaction safe. This is non-trivial,
I know :-).
Regardless, the first option seems the less of the two evils.
Gavin
Tom Lane wrote:
There are a number of statements, such as TRUNCATE TABLE, that refuse to
run in a transaction block because they perform actions that can't be
rolled back later.
These statements currently do not look at autocommit, which means that
if autocommit is off, their tests will
Bruce Momjian [EMAIL PROTECTED] writes:
... I think we
should just do an automatic COMMIT if it is the first statement of a
transaction, and if not, throw the same error we used to throw. We are
performing autocommit for SET at the start of a transaction now anyway,
so it isn't totally
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
... I think we
should just do an automatic COMMIT if it is the first statement of a
transaction, and if not, throw the same error we used to throw. We are
performing autocommit for SET at the start of a transaction now anyway,
so
Bruce Momjian wrote:
most useful approach. The analogy to SET hadn't occurred to me.
Yea, the SET behavior appeared pretty queer to me, but now that I have
used it, I am getting used to it.
So does that mean:
set autocommit to off;
begin;
insert into foo values('a');
insert into
Joe Conway wrote:
Bruce Momjian wrote:
most useful approach. The analogy to SET hadn't occurred to me.
Yea, the SET behavior appeared pretty queer to me, but now that I have
used it, I am getting used to it.
So does that mean:
set autocommit to off;
begin;
insert
Bruce Momjian wrote:
Joe Conway wrote:
Bruce Momjian wrote:
most useful approach. The analogy to SET hadn't occurred to me.
Yea, the SET behavior appeared pretty queer to me, but now that I have
used it, I am getting used to it.
snip examples
In the last case, the TRUNCATE will
Gavin Sherry wrote:
On Fri, 18 Oct 2002, Tom Lane wrote:
Anyone see a way out of this catch-22? If not, which is the least
bad alternative?
Ultimately, fix TRUNCATE to be transaction safe. This is non-trivial,
I know :-).
Regardless, the first option seems the less of the two evils.
Mike Mascari wrote:
Gavin Sherry wrote:
On Fri, 18 Oct 2002, Tom Lane wrote:
Anyone see a way out of this catch-22? If not, which is the least
bad alternative?
Ultimately, fix TRUNCATE to be transaction safe. This is non-trivial,
I know :-).
Regardless, the first option
29 matches
Mail list logo
