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;
> > EN
> 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:
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 t
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 'plpgsq
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
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?
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.
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
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 R
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 la
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
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
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:
> >>> ... 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 stran
>>> ... 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,
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 m
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 n
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 kn
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 :-).
> >
> > Regar
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.
Even
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
--
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.
In the last case, the TRUNCATE will happen, and the INS
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;
>b
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 ba
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 any
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:
> 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 wil
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 .
28 matches
Mail list logo
